In episode 1 of Swimm Upstream, Host Tom Ahi Dror speaks with Ryan Atkins about everything from recruiting, engineering onboarding, and ensuring that mentoring dev teams are culturally valued by organizations. Ryan is the Head of Engineering Operations at Asana.
Hello, everyone, and thanks for joining us on this episode of Swimm Upstream, a podcast devoted to engineering team leads and dev tool enthusiasts. I'm Tom, co-founder of Swimm, and today we're talking with Ryan Atkins. Ryan has had a fascinating career - a graduate of Stanford University. Ryan was a physics, computer science, and math teacher before working for some of the best companies in the Bay Area: Dropbox, Stripe, and now Asana. At Asana. He's an Engineering Operations Lead. Hi, Ryan, we're excited to have you on.
Thanks for coming to speak with me today.
Thanks so much for having me. I'm excited to be here.
So we have a great set of questions for you today. So let's jump right in. Ryan, at Swimm, we take coffee way too seriously. So to start things off, if you could have coffee anywhere, where would it be this morning?
Well, I'm having coffee right now, in my office. I wish I were having it in Costa Rica, because Costa Rica, in my opinion, has the best coffee. If you haven't been there, you should try to go to Costa Rica.
I haven't been there. I have... I've had coffee from Costa Rica. But I imagine it's not the same experience at all.
Got to be there in person. It's great.
Okay, so hopefully, this is over. But you know, this part this past year and a half have been mostly focused on adjusting to new realities of COVID-19. And what's one thing you learned to live without that surprised you?
This is kind of surprising. But I would say driving - just like not having to really go anywhere and driving way less. I always love driving - being in control and exploring. But it turns out it's kind of overrated. It's kind of nice to...to lay low a little bit.
Okay. So, Ryan, please describe for us what you do at Asana without using your title.
I'm asked this question a lot, even with my title. So I will explain that generally, the way that I explained is, I help make engineering organizations more effective, efficient, and engaged. And I do that by building systems and processes, and tools, all with a focus on improving engineering culture, primarily.
Okay, and now, there's an obvious question here, and that is how much being a teacher has informed that type of work?
A lot, actually. So I spent just over 10 years as a high school physics teacher, and there's a lot of managing other people - and influencing with sometimes small, sometimes major, like directives to sort of shift the organizational culture of something. It's so critical in a classroom, and it's so hard. And I feel like honestly, if you could do it with 13, and 14-year olds, then you have a good shot at influencing, you know, people in their 20s, 30s, 40s plus. Like, there's a lot of transferable skills in how you think about getting a group of people to behave in a certain way - that's productive and helpful for them as well.
So it's the classroom or the engineering organization as sort of a creature, right, that you are trying to change its behavior.
Yeah, exactly. It's an ecosystem. It's a system, and there's clear inputs, and we have more power than we probably think at setting up people for success. And the other thing that I think is really critical when you work on organizational change; it's often slow. And I think being a teacher has really helped sort of increase my patience for letting some experiments sort of run over time - and to understand what impact that you're having. I think it's really hard in software where, you know, you have short release cycles, and you can see changes tangibly in front of you, and you can measure their impact quickly. But with a lot of organizational strategy and design, you have to be patient and let things play out a little bit because often the impact is latent, and it's just inherently harder to see. And the same thing is true when you're trying to, like influence the trajectory of a 13-year-old's education or life. That it takes, you know, constant nudges to get them headed sort of in the right direction.
That's fascinating. In the Bay Area, its said that turnover is very, you know, fast. And I wonder what that means in you know, with the processes that you're trying to do and making people get used to new situations and new processes. Does it make it harder or easier that turnovers is high?
Great question, you sort of led me into this, but I think it's both. I think that the infusion of newness is always really good. And you can get that newness if you do have, you know, sort of a lot of turnover and people coming in. Or newness often comes with growth and scale. And that's great. There's also so much value in, you know, longevity and tenure of individuals. We talk a lot about tribal knowledge that’s sort of stored up in your codebase and in your culture, and how you can kind of make that explicit, so you're less dependent on tribal knowledge. The other things are just like the criticality of onboarding and being so deliberately conscientious about the way that your culture is shaped when you have so much change happening. I think it makes, you know, fortunately, roles like the one that I'm in, more useful and valuable to try to help navigate a lot of that change.
Okay, and, you know, you've worked with - for late-stage startups, right? So, and I imagine, in each one of those you had, like this tight group of people that were there from the beginning, or at least close to the beginning. And do I imagine correctly that this is like a group you need to recruit because they're very important for the culture and so on?
Yeah, I think I mean, the companies that I've worked at have always been founded by, you know, engineering and product leaders. And if you look at things like the proportion of engineers in the first 100 employees, it's often quite high. And then you have some - you have a number of emerging leaders that grow from that original sort of population. And you definitely are - I mean - we are always recruiting. Literally, if you talk to anyone at Asana, we say we talk about ABR: Always Be Recruiting. And yeah, finding the right set of people is hard, and you're constantly competing against the other best companies in the world for the best talent in the world. And, yeah, finding, finding people that can thrive, and I don't know, maybe we'll get into this a little bit. But it's really hard to enter a company where there is so much historical and institutional knowledge. And how do you sort of - like get up and running - and get up and running quickly is just an inherent challenge. Especially, a lot of these companies are, you know, going through growth. But you know, Asana is ten years old. When I joined Dropbox, it was already eight years old. Stripe was already, you know, six, seven years old by the time I joined. So these companies have, you know, a lot of history that's already there, that's worth understanding and hard to understand.
Okay, so you mentioned onboarding several times. And I know this is something that you've worked on a lot. So in your current role and previous roles, what was your focus in making engineering point boarding better?
There's always, so it definitely depends on sort of the scale of the company. But there's, there's some foundational sort of cornerstones I think, really matter a lot, for really great engineering onboarding programs. The first one is the institution of mentorship and making sure that it's culturally valued. I think that's the most critical thing. A lot of companies will have you show up - day one - you have an onboarding, onboarding buddy, or some mentor who's gonna walk you through a checklist of things. Making sure that role is valued, there's a steam for it, time is protected for it, you recognize mentors are doing a great job, I think that is really, really critical. The other thing, and, you know, sort of hat tip to the whole, like swim kind of metaphor here - is I think a lot of companies believe that the best way to onboard people is to like, allow them to gradually wade into the water, and like slowly expose them to various systems.
But that's just not the way it works. Instead, like you get people, you drop them into the middle of the ocean, and it's deep. And you know, you say swim. And so instead, instead of like trying to make them wade in, just make it easier for them to survive when they do jump into the deep end. And you do that by providing them with structure. And I think a lot of onboarding programs that people that I talked to focus on the what. Like, here's, here's what we're building, here's what tools we have. But you really need to explain the why, like the historical context. Why we chose this, why we made this tooling decision or this architecture decision, how we prioritize. Like, how do we value things that help influence what decisions we make?
I - at every single company I've worked at, I've introduced a new onboarding course that is simply called like the structure and culture of engineering. And it's just about like, here's our organization. Here's how we've divided up our teams. Here's who works on what and why. And I think that you need that sense of clarity and you also need you know, what is the cultural like zeitgeist? What are people thinking about and caring about when they join a company? Because every... You know, you just suddenly are introduced to this moment in time and being able to have that sense of familiarity and understand what people care about.
So at Asana right now, I'll give you an example. We are all talking about returning to the office, and what is that transition going to look like? How are we going to handle that? That, by far, has been sort of like the biggest change. We also talk a lot about things like the role of titles and engineering organizations and how we recognize and celebrate career growth. So having new engineers sort of understand that this is what people are talking about right now can really help them feel a sense of belonging earlier.
That sounds like a lot. And you know, I guess, first of all, I agree with a lot of what you said, and I'm very happy you said it. I think a lot of people hearing this can - might think, wow, my onboarding process in my company really sucks. And, you know, what are the chances if I don't have someone like Ryan that I can make this work? And I wonder, is there like, one thing, if you were visiting for a day, in an organization, what's like the quickest fix that would make the most impact that you would start with?
Quickest fix, aside from hiring someone to work on engineering operations to maybe not be quick.
I think. I think I want to go back to what I said before about really evangelizing mentorship and making sure that mentors feel supported. And that that work matters. You'll see more and more companies that reach a certain size of scale, and they begin to develop like their career levels and ladders. We call their success guide at Asana. And baking into that, that mentorship matters, like this is high impact work to scale yourself.
I think a lot of companies typically like focus on recruiting. It's like it helped us hire, and that's great, you're gonna - you're gonna multiply your impact by bringing on the next great set of engineers. But also, you can multiply your impact by speeding up and accelerating their growth and development.
So that's one thing I'd say. The other thing I said is, try as best as you can to measure the effectiveness of your onboarding program, and that even if it's subjective. And you're asking people 30, 60, 90 days in, like, do you feel like you belong? Have you been able to, you know, make meaningful impact? Survey the new hires manager. Set up some structure that will give you a feedback loop to know if what you're doing makes a difference. So set up mentorship, and set up some feedback loop by measuring the effectiveness of your onboarding program.
I have a question about mentors. So you can have - I'm sure you've met developers that can be awesome developers. But if you ask them to mentor someone, they would probably do a poor job. And I wonder, and maybe this goes to, you know, the way you think about teaching as well. Are there developers that should never be mentors? Or can anyone be a good mentor?
Ah, that's such a good question. I think I will dodge the question slightly and so that everyone can be a better mentor. And so everyone has the opportunity to grow and to improve. I do believe that effective mention - it can be based on a system of incentives that help to change people's behavior to value mentorship. And that you can learn and grow and certainly it will be harder and more difficult for other people. I think that you have a cultural problem if people don't see the value in mentorship, even if it's not in their skillset and strength. You probably, as a business, have very few, you know, projects or avenues where someone can work in isolation and deliver complex value in a way that's sustainable to your company. Right? If you have that. And you have an engineer who doesn't want to mentor or collaborate and can be this like knowledge silo, then that's okay. But very few places do. You know, software development is a team sport, and collaboration is really critical. And so...
You're tying collaboration and mentorship together?
That's, that's a beautiful concept. So basically, you're saying if this person can't really mentor, then he, he or she probably has a problem with collaborating as well. I'm very sorry - we're nearing the end of the time that we have because I feel like we could have continued this for hours. Last question that I do want to ask. So it sounds like you were involved and led a lot of initiatives, very different ones. What are like the one or two that you remember most fondly or are most proud of?
I feel like I keep hammering this point, and I probably should talk about more diverse things, but mentorship: building systems of mentorship. Just - I take a lot of pride in being a connector and like allowing great people this, I feel like my ability to multiply - my impact is connecting two people that will derive a lot of value from each other - and so building up structures that enable that to happen, making it important. Some of the things are looking at your engineering onboarding mentor and asking people a year later, like - who was your engineering onboarding mentor? And making them remember that and recall that not letting the history die. And that culture is built around history. And so there's just so many different mentorship programs that I put together. I also, you know, firmly believe part of my character and being a teacher at heart is empowering other people to achieve their potential. So how do you do that? How do you help them grow? And I think just mentorship is so valuable there. So that one kind of stands out to me as something that I've worked on in every place that just feels really high impact and valuable.
So it sounds like our listeners, like the one takeaway from this talk would be - build a mentorship program if you don't have one. And if you have one, make sure that you're doing a good job there. You're motivating right and, and you're - and you're providing enough time and context and motivation and so on. Right?
I yeah, that's perfect. It's hard to know where to start. I think onboarding is great. Like if there's interns, you could look at new grad hires, you could look at sort of the other spectrum of like senior staff level engineers. I like finding a pocket to focus on, build out what works, but really think critically about how you are culturally incentivizing that behavior of mentorship because it will pay itself back in time.
Amazing. So that's unfortunately, that's all the time we have for today. Ryan, thank you very much for coming on.
You bet. It's been a pleasure. Thanks so much for having me.
Thank you everyone for tuning in. And I hope you join us for our next episode to find additional episodes and full transcripts, or if you'd like to be a guest on our show, find us on our community page at Swimm with a double m dot io. Bye for now.