Skip to main content.

Ryan Kahn - Building Better Teams

Season 6, Episode 7 | September 29, 2022

In this episode of the podcast, Dan and Bekah talk with Ryan Kahn about building better teams to deliver quality software by practicing empathy and knowledge sharing.

Ryan Kahn

Ryan loves solving the human and technical problems of software development, and works on both as a developer experience and productivity consultant. He lives in New York City with his partner, daughter, and dog. Outside of his work he loves Astronomy and Amateur Radio.

Show Notes:

In today's episode, Bekah and Dan talk to Ryan Kahn, a developer experience and productivity consultant from New York City, about his work as a consultant helping companies to build better software teams. He emphasizes the importance of recognizing that teams are made up of individuals who have different needs and approaches. He also breaks down the difference between quality, technical, knowledge, and innovation debt and the need to identify which most impacts teams as they seek better communication to build a stronger team.

Links:

Sponsor Virtual Coffee!

Your support is incredibly valuable to us. Direct financial support will help us to continue serving the Virtual Coffee community.

Please visit our sponsorship page on GitHub for more information - you can even sponsor an episode of the podcast!

Virtual Coffee:

Transcript:

Bekah Hawrot Weigel:

Hello and welcome to Season 6, Episode 7 of the Virtual Coffee Podcast. I'm Bekah, and this is a podcast that features members of the Virtual Coffee community. Virtual Coffee is an intimate group of developers at all stages of their coding journey. And they're here, on this podcast, sharing their stories and what they've learned. And we are here to share it with you. Here with me today is my co-host, Dan.

Dan Ott:

Wuddup, Bek? How's it going?

Bekah:

It is- it is going well. How's it going with you?

Dan:

[Chuckles] It's going okay. Yeah, we have a great episode today. We met with Ryan Kahn, who has done a lot of things through his career. He was a teacher, he's a developer, and now, Ryan is a consultant who comes and helps teams improve their collaboration and their communication skills.

Bekah:

I loved how Ryan talked about the importance of empathizing with your teammates and treating each person as an individual human being who makes up your team. I think that that's a really great approach in order to, you know, empower your team to do what they can do and the best ways that they can do it.

Dan:

Yeah, absolutely. I- I mean, it was- it was -- Ryan's -- I mean, Ryan's always great to talk to, and, yeah. And that- that, like, that- that philosophy, I think, I don't know, lines up a lot with a lot of the stuff we talk about here at Virtual Coffee. So, it was nice to hear him talk about it. And it's nice that he is -- he's doing this, like, he's -- I wa- I was very interested to hear about his consultancy, and his- and his, like, sort of new journey that he is doing because it's a little bit of a different approach than, you know, most people. I'm- I'm a consultant myself, but I just kinda come in and I do, like, the work, right? Or like, you know, the kind of stuff you- you think about, right? And this is more, Ryan's gonna come in and help teams improve their whole situation, right? And then leave [chuckles], you know? And I think that's really great. I think it's a- I think it's a very cool thing to do. And I was excited to hear about it.

Bekah:

Yeah. It is really something that I think is undervalued too. So I think that a lot of teams experience these problems and they just end up having a lot of turnover, or burnout, or things like that. And there's not a huge focus on what Ryan's doing, but I think it's something that should be focused on. It's really needed in the industry.

Dan:

Yeah, I agree.

Bekah:

Well, we start every episode of the podcast like we start every Virtual Coffee. We introduce ourselves with our name, where we're from, what we do, and a random check-in question. We hope you enjoy this episode. Today's intro question is, if you could remove one task from your day, what would it be? My name is Bekah. I am a technical community builder from a small town in Ohio, and if I could remove one task I -- email, or -- no. Meetings. Can I remove meetings? That's kind of like general, but I would get rid of most of them.

Dan:

So, all meetings? All right.

Bekah:

Only the-

Dan:

I'm used -- I mean [laughs] --

Bekah:

-only the ones I wanna get rid of. The ones without agendas. Those ones.

Dan:

Sure.

Ryan Kahn:

Not this one, I hope.

Dan:

Well, this isn't a meeting, this is- this is an event, right?

Bekah:

Mm-hmm. This is an event.

Dan:

Yeah. Alright. Hi, I'm Dan. I am in Cleveland. I do website development. And, yeah, I think -- the first thing that popped into my mind was like bedtime stuff with the kids. I- I don't mind like the all the way at the end reading books and stuff, but it's all the, you know, bath and whatever, all that nonsense. But then, I think, actually, it's getting them in the car.

Bekah:

Oh.

Dan:

There's -- I -- my, you know, I still have a 3-year-old and a 6-year-old, and so they're still all, both in car seats, you know, and all that stuff. And doesn't matter where we're going, what we're doing, it takes just for, like, ever. Like, I sell them to go outside cuz they can get into the car by themselves, you know? And I tell 'em to go outside and get in the car. And I go outside, and they're just like wandering around in the garage or whatever, you know [laughs]? I'm like, "Just- just get in the car. We just need to go. This is -- we don't have to do this every time." And like, playing with toys while I'm trying to get them buckled and all this stuff. So, that's gonna be my answer. Yeah. Putting the kids-

Bekah:

That's a good one.

Dan:

-in the car. They could just, like, snap [fingers snap], and they would just be strapped in the car. That would be --

Bekah:

With their shoes on too, right?

Dan:

Sure. Yeah, yeah, yeah. Exactly. Yeah.

Bekah:

I don't know how many times we've been in the car and a kid doesn't have shoes. Like, my kids are all ... older. My youngest is five and a half, but frequently, we end up in the car, and, like, one kid's like, "Oh, I did -- I didn't bring any shoes." Like, "Why? What? How is that a thing?" [Dan laughs] Like, "You just always ..." "You didn't tell me I needed to put on shoes." "You always put on shoes if you're getting in the car." Like --

Ryan:

Standard operating procedure.

Bekah:

Yeah.

Dan:

Yeah.

Ryan:

Okay. Well, I'm Ryan. I am a developer experience consultant and productivity consultant in New York City. A little- little town in New York called New York City. My daughter is little over one year old. So getting her in the car is very easy. We just pick her up, and put her in, and she doesn't have much of a choice about it. And if she needs shoes, we put 'em on. And, yeah, meetings. I actually like meetings. I think that that's when I do my best work. So I won't say that. I will say dishes. That is the one thing that my wife and I [chuckles] have the most tension about is actually just doing the dishes. Cuz neither one of us likes to do it. So I would remove that from my day in a heartbeat.

Dan:

That's fine [??]. Yeah.

Ryan:

Just, I mean, I would want clean dishes. I wouldn't wanna just not do it and have dirty dishes. But if the dishes get clean regardless, that's what I would pick. Yeah.

Dan:

I like that. Yeah, I actually, of all the, like, household chores that you have to do all the time, dishes are like one of the easiest ones for me. Like, in which, you know, I -- chores are like a pain -- I don't mean easy. Like, easy to get myself to do, you know? I think I can listen to podcasts and stuff, and so it's, I don't know.

Ryan:

Yeah. It's rather meditative.

Dan:

It doesn't bothers me when I'm doing the dishes. Yeah, exactly. Exactly [chuckles]. I'm, like, if I'm doing that chore, then, you know, that everybody -- somebody else is dealing with the kids [laughs].

Ryan:

Hmm. A little break.

Dan:

Oh, man. But I don't like putting the dishes away, honestly. That's my --

Ryan:

Oh. Well, you know, it's --

Dan:

That's, like, I don't mind cleaning them. It's like putting them away is the thing that always bumps me on.

Ryan:

Our dishwasher's actually broken right now.

Bekah:

Yeah.

Ryan:

So, all the dishes are done by hand, which is probably why it's front of mine, for me.

Bekah:

Our dishwasher was broke for like over a month. And it was- it was the source of a lot of tension in the house [laughs]. Like, we have four kids and then some of them like take plates in their rooms and then you've got like crusty dishes. Like, what are you doing?

Ryan:

And my wife does that.

Bekah:

Well, Ryan, we are very happy to have you here with us today to talk about a lot of different things. But building better teams I think is gonna be a great source of our conversation. But before we get to that, let's hear your origin story. So, how did you get to this point in your tech career?

Ryan:

Yeah, thanks. I mean, I always approach this story a little differently every time I tell it. I mean, I've always been interested in computers, right when I was a kid. I remember the first kind of computer programming thing- computer programming thing that I did was, there was a video game I liked to play and it was kind of like Iron Man mode where like if you die, you die. And I- I had a big career in the game, and then I died, and I was like, "Oh, my god." I was so depressed. Probably the first time I was ever depressed in my life that I remember was [chuckles] I dying in this game. And so, I came in, and I- I took the save game file, and I switched around the bits, and made myself alive again. And so that's where I started out. I think with the, you know, I always was interested in DOS, and kind of playing video games. And so, I've been talking to the computer for many years, is what I call it, through the terminal. But yeah, I never considered it as a career, you know? I had a teacher in high school who got me into economics. And so I decided to study that in college. But, you know, college didn't really agree with me for mental health reasons. And so I dropped out and I was working actually on a loading dock. Cuz I had a- a CDL, like a truck license, but I couldn't find a job driving a truck. So I got a job loading the trucks. It was the middle of the- it was in the middle of the night. It was, you know, I learned a lot on that job about hard work. But, you know, it wasn't really what I wanted to do long term. And a friend of mine who I met in college was like, "Hey, do you wanna be a software engineer?" So, I mean, this is kind of the- the height of privilege, right? It's like someone just offers you a job and you don't have to apply. And, you know, like, I- I- I feel for everybody these days who is looking for a job as a software engineer and really kind of has to look, and look, and look. You know, for me it just fell in my lap even when I wasn't looking for it. So, a lot of privilege there. And, yeah, so, you know, I started off doing that job. It was like a government contracting job. I actually really enjoyed it. I remember the first problem I solved, which was putting a ClickHandler on a button [chuckles]. And, you know, I- I solved it sort of the -- I put- put it in the HTML as, like, text, which is, you know, not how you even did it back then with jQuery and stuff like that. This was back in 2009. And yeah, so I didn't even solve it kind of the right way, but the elation of having solved a problem was huge and I kind of tried to stay close to that feeling. Kind of like, you know, with switching the bit in the save game file, just trying to stay close to that feeling throughout my career. And, so I did that for about four years. You know, my boss was like, "I'm not gonna pay you anymore than you're making now." And I was like, "Well, I could make more money." So I went to another job-

Dan:

Mm-hmm.

Ryan:

-a private sector job, cuz the first job was a government contracting job. And, you know, I enjoyed that too. You know, it's -- it was in DC. It's not, like, a big market. So the company that I worked for was a little bit, you know, janky, I would say. Kinda like the first one. But I learned a lot at that job. I worked with a lot of great engineers, learned a lot about what I didn't want in a job. And at the same time, I- I went to a meetup for General Assembly, and they asked me, "Hey." Someone just came up and said, "Hey, do you wanna be a teacher?" And I immediately said, "Yes." It's something I hadn't really thought about, but I was always on Stack Overflow, just kind of answering questions and- and so, it just was an immediate yes for me. Like, I just kind of -- it blurred outta my mouth, you know? Like joy, without me even thinking about it. And, yeah, so I- I did some teaching at General Assembly, and that was sort of the end of my programming career, even though it lasted for another seven years or something. Actually, I don't know how long, but it lasted for a long time after that, even though I decide -- I decided at that point that I wanted to solve human problems in software, and not so much solve the- the programming problems. But I kept grinding at it for many years, moved to New York, I continued to teach at a company called Thankful. Just worked at Squarespace first, and then Dropbox, and then eventually just, you know, kind of burnt out on development. Cuz again, I- I kind of had already found something in my calling a little bit, in something else related. And so now I work as a consultant. And I guess we can talk about that. But, yeah, it's, you know, what I'm trying to do is help teams be more knowledgeable and more productive, and deliver kind of on a promise of quality, you know, and- and-, and timelines. So that's what I'm trying to do as a consultant. But that was sort of an evolution from teaching. You know, from teaching and- and solving human problems. So that kind of brings me to where I'm at today. And then, you know, of course I'm in VC, which is a wonderful community. And that's been a source of great joy for me. And you'll make other communities that I'm in, but this is kind of the main one that I- I appreciate the most. So yeah, that's kind of where I'm at today.

Dan:

We're the- we're the best one, obviously. So --

Ryan:

Well, the most welcoming, right? [All laugh] The most welcoming tech community. I've started to get the invite, so I'm really happy about that. I hope we can continue to expand at a- at a measured rate-

Dan:

Yeah.

Ryan:

-with, you know, people who are aligned with the vision.

Dan:

Yeah. That's been so fun to have new people back, you know, coming back in. It's been- it's been fun.

Ryan:

Yeah.

Dan:

Well, Ryan, thank you for-

Ryan:

Yeah, I'd like someone -- go ahead, go ahead.

Dan:

-oh, go ahead. I was just gonna say thank you for-

Ryan:

I said --

Dan:

-that story, but --

Ryan:

Yeah. Okay. Sure. Yeah. Yeah. It's- it's- it's a story that has other parts to it, of course. It's hard to kind of like capture a -- the multidimensional nature of human beings in a- in a short blurb. But yeah, happy to talk more about it as we go forward.

Bekah:

Was there a moment in -- when you were teaching, that you really felt, "This is what I wanna be doing," or do you think the whole experience just kind of led you down this path?

Ryan:

Well, there was a moment when I was like, "This is not what I wanna do," right in the beginning. You know, I taught HTM- I taught a front-end course at General Assembly, and, you know, I taught HTML and it was great. I was like, "Oh, my god. I'm such a good teacher, people love me, I'm getting great reviews. Like, this is what I wanna do." And then we got into JavaScript. And to be fair, there was no curriculum, you know what I mean? Like, this -- they just opened this office and General Assembly was rather — I don't know how young it was — but it seemed pretty- pretty startup-y. And so, there was no curriculum. So I had to make it up as I went. And, you know, I didn't do a good job at that, initially. It's very tough to teach JavaScript. And so-

Bekah:

Mm-hmm.

Ryan:

-[chuckles] I got all these bad reviews. People love me, still, cuz I'm like a nice person, but they were like, "He's a nice person, but he's not a good teacher." And so that was sort of a lesson for me. It's like, okay, prepare how do you actually, you know, teach really hard material to pe- to a variety of people? So I learned a lot from that. But, you know, the initial kind of, you know, I wouldn't say high, but the initial sort of like, joy of teaching was that first kind of semester part of it, the first half of the course. And I really enjoyed that. And that kind of carried me through even the tough time of like, you know, not doing well. But I also realized from that, that I wanted to do individualized mentorship more than I wanted to do teaching in general, you know? And I still kind of struggle whether I wanna do conference talks or -- cuz I do like what I can do in conversation rather than what I do in kind of multiplexing, if you will, to a bunch of people. So yeah, I think teaching is great. I do enjoy kind of getting up in front of people actually in the- the kind of nervousness of that. And -- but I do enjoy the individualized mentorship better and that's kind of where I- I think I shine, is pair programming and, you know, conversations. So ... yeah.

Dan:

Yeah. That's- that's really cool. I was- I was -- well, I think that's actually the answer. But I was gonna ask, you know, you talked -- when you were talking about before you were teaching, that feeling, right? The feeling fixing the game or-

Ryan:

Yeah.

Dan:

-adding the ClickHandler, right? You were talking about staying close to that feeling, which I -- which is, I- I turn a phrase that I love and also something that I've sort of un- you know, unintentionally or intentionally, sometimes, try to do, throughout my career. But my- my question was going to be like, how do you stay close to that feeling when you're not- when you're not solving technical computer problems anymore, right? How -- like, what- like, what are ways that you can -- that you do stay close to that? Because I- I imagine you do, but it's just a little bit different. And so, I was wondering if you talk a little bit about like how you -- or if you've thought about that at all [laughs]. How you stay close to that feeling now?

Ryan:

I have. I have. I think-

Dan:

Yeah.

Ryan:

-about it all the time actually [laughs].

Dan:

Yeah.

Ryan:

Well, for me, it's the concept, you know? There's a Buddhist teacher named Suzuki Roshi who had a great phrase, which is 'In the beginner's mind, there are many possibilities, and in the experts mind, there are a few.' And so I- I just remember the beginner's mind. I try to remember that I don't know, basically, anything. You know what I mean? Like, you've had experience with things, you've seen some problems, but every problem you solve is totally new. It's, you know, it's like, it's some new combination, some new context, some new outcome you're trying to achieve, some new technologies. And so I try to stay close to beginner's mind as much as I can by reminding myself that I don't know, and going from that sort of area of possibility rather than sort of the preconceived notions. And so in my current work, I try to work with companies that want to hire junior developers. I think that's sort of the -- I'd rather work with companies that are trying to integrate juniors rather than companies that are obsessed with, you know, seniority. And the reason for that is that helps me stay close to beginner's mind by working with beginners. You see the kind of endless possibilities in their mind. As they create sort of quote, unquote bad code, it's like -- that's actually creative code. It's creative problem solving. It's not like they're just wrote -- writing down something they already know. They're really trying to solve a problem from a standpoint of possibilities. And so, yeah, I think working with beginners is how I stay close to that feeling. In addition to kind of cultivating it in my own mind, I try to experience it through the minds of actual, you know- you know, beginners. So yeah, I think that's- that's kind of the answer is, I- I try to stay close to that feeling and then that allows me that excitement when other people solve problems. When it clicks for other people. That's where, like, it clicks for me too, you know? It's like I- I don't know that I could do it. I mean, I, you know, if I'm solving a problem myself, some sort of, you know, big scope problem as you get when you're more experienced, there's clicks for, you know, it clicks for me too. And I get that- that feeling of like, "Oh, it works," you know, "There's no errors." Or, you know, the TypeScript compiler says, "Go ahead," you know? That's- that's good stuff. But I do love feeling it click or seeing it click beginners, and kind of experiencing that joy secondhand.

Dan:

That's awesome. That's very cool. Like, being able to stay close that feeling, right? By sharing it with other people, you know? I-

Ryan:

Well, it's the best way [unintelligible].

Dan:

-before I ask this question -- yeah, yeah. Totally. Totally. You know, and you had- you had started talking about -- on how you, like, doing more one-on-one, you know, pairing stuff like that, with people, and I imagine that's -- it becomes a lot easier to do that, right? To- to- to share in the experience when you -- when it's a more intimate, you know, learning situation, right? With one, you know, one-on-one sort of thing, instead of, like, teaching a class, for instance.

Ryan:

It's true.

Dan:

How it's easier to- easier to close to that feeling [chuckles].

Ryan:

Also I've found that -- exactly. And also I've found that -- I mean, this is an ADD trait. But, like, if you tell me to go off and do something, if I'm not interested in it, I'm not gonna do it [chuckles]. And so, like, that's why freelancing [unintelligible] --

Dan:

Hm. I dunno if I think about that [all laugh].

Ryan:

Well, yeah, exactly. So, you know, it's- it's tough for me to kind of do programming on my own. And I've found that, like, if someone else holds the focus, like in pair programming, or if it -- if it's something I can do in the context of a meeting, you know? Like, I just kind of go in, I do the meeting, I come out, I go back to my life. Like, that is actually where I do my best work, is something I can do in conversation, in- in- in collaboration. Where someone else holds the focus, I can do the best work. But, so that's sort of another thing about knowing myself, right? It's like knowing where I work best and not trying to, like, fit into someone else's life as a- as a software developer, you know? So, and also trying -- it took me a long time to kind of release myself from the view I had of being a software developer, cuz it was such a part of my identity. And so it's- it's tough, like, to say, like, you know, to give that up to say, you know, I don't wanna be a software developer so much anymore, as much as I wanna help other software developers. Like, that's a -- it was a mind bending thing, you know? Cuz I was so used to seeing, you know, to- to telling people I was a software engineer. I still do sometimes cuz it's much easier than explaining what I try to do, you know, if I don't really wanna have the conversation. If it's just some- somebody doesn't know the difference anyway. I'll just say, "Oh, I'm a software engineer." But it's still true. I do a lot of engineering on my own. But, yeah, pair programming, things I can do in conversation, is where I really shine.

Bekah:

So when you're working with teams, how do you kind of transfer that same energy to teaching within a team, or what do you think the role is and how that's translated from your experience to what you're doing now?

Ryan:

Well, I mean, first you have to know the team, right? You have to kinda know what their individual problems are. You have to talk to them. And so, you know, I- I start with like an audit, where I go in and kind of identify the pain points for people. So that way, when I go pair with people, I know them. And I know the kind of what they're working on. I know where they're struggling. So yeah, I think that, yeah, knowing- knowing people, knowing the people on the team is kind of the most important thing, and being personal. You know, I don't -- I'm not writing a book, right [chuckles]? I'm not writing a book on how to solve all the problems. If I was doing that, I mean, that would be great too. But it's like I'm really creating an individualized plan for people and companies as well, you know? There's a plan for the team. There's also a plan for individual pe- individual people for how to improve, how to- to do better. So, yeah. I think I've actually forgot what the- what the feeling was you were asking about, but I think that's sort of maybe an answer. I mean, if you- if you have a follow up, I mean, maybe I can get back on track. But that was the first thing that came to mind [laughs].

Bekah:

Yeah. Well, I mean, it's a hard balance transitioning from doing like one-on-one mentorship and teaching-

Ryan:

Oh, yeah.

Bekah:

-to going inside of a team. And I think that idea of getting to know people is super important because I- I think that you can be way more effective as a teacher if you do know the people in front of you. Because, like, I- I think. So much of the time we depersonalize what we're doing or we abstract these concepts out and try to apply them rather than, like, recognizing, like, there's a dynamic group of people in front of us and this approach is not going to work unless you have an understanding of who those human beings are. And I think that's, you know, having those conversations and the -- like, we do in Virtual Coffee and the breakout rooms makes a big difference. And there- there can be a real balance of like trying to have that personal experience, and having empathy, and then also teaching in that situation. So do you have any strategies for being able to balance those things?

Ryan:

Well, you know, I- I think there's -- I have sort of a view on learning. I mean, I have a lot of sound bites, right? That I say over and over again. But, you know, my view on learning is that a knowledge is that -- it's -- there's nobody has the same knowledge. We all think that like, "Oh, I learned React, you know React, like, we know the same thing," right? But actually, you know, the way we really learn is by connecting to our experience. We have all these analogies that are personal, that we use to kind of identify and understand problems, understand solutions, understand technologies, and so it's really like a 3D space where nobody really overlaps. It's like you have this sort of bubble of knowledge in the- in the problem space. And it's very multidimensional, it doesn't overlap with other people, it's centered around you. And so I think when you're working with a team, it's like, you have to kinda understand that a team is a collection of individuals who have common goals. It's not like a unit. Like, you know, in the military or something where everybody just sort of like follows an o- I mean, I don't know. I never been in the military. But you know, it's like that software team is very much like individual people tackling problems individually. And I think that, the other thing is, trying to break that cycle and improve kind of pairing and knowledge sharing between the team. Because a lot of times, I mean, the teams- these teams I've been on, it's like you come in, and people are individually working on problems, your individual productivity, everybody's trying to burn down their sprint points. And, you know, there's not like a lot of, you know, some people will come up and ask a question occasionally, but there's not, like, teams working together. And so I think the- the ultimate thing is I don't wanna be there in long term, you know? I'm not there to, like, be the teacher forever. My- my goal is to change the team dynamic to make everybody a teacher, you know? Make everybody sort of a learner. And everybody a mentor, you know? Not -- obviously, people have different capacities and interests in it. But, you know, just improving their ability to do it in their own way. I think is kind of -- I think that answers your question. I always get off on these tangents, but I think that's sort of how I approach the team dynamic, is really trying to make myself irrelevant [chuckles]. Make myself not necessary in the long term. Cuz again, I wanna work in limited engagements. It's again, an ADD thing. I'm not trying to make a year contract with somebody where I'm just, like, constantly grinding with them. It's like -- no, I wanna make them better in a short term, in an impactful way. Like you do the- do the judo move where you just sort of like come in and flip things around and leave, you know [chuckles]? That's kind of my ultimate goal. Is not to- not to be -- to make people dependent on me, to make people self-sufficient.

Bekah:

I think that's great and I think that one of the biggest things that I see or hear in the industry is it kind of takes a breaking point to bring somebody in to rectify communication and team ... I don't know what the right word is.

Ryan:

Dynamics? Or --

Bekah:

What would you -- what did you say?

Ryan:

Effectiveness? A dynamics, effectiveness --

Bekah:

Yeah. Team effectiveness, dynamics.

Ryan:

Yeah. Proactivities something.

Bekah:

You know, people wait until there's a problem. And I feel like bringing someone in very early on can reduce miscommunications, burnout, problems that you see because you haven't spent that time developing communication. And I don't know if this is particularly a startup issue, but like, the whole move fast and break things, I feel like there's a lot-

Ryan:

Oh, yeah.

Bekah:

-lost in how we communicate within teams and cross team communication. So, like, what- what is your ideal situation to come in? Would you like to come in from the beginning? Or do you like to come in and kind of like blow people's minds by fixing their problem?

Ryan:

That's a good way to put it. Yeah, I mean, a lot of the things I offer are counterintuitive, right? Like, slowing down, like, you know, not going, moving fast, and breaking things, but instead, you know, allowing people the time and the- the ability to talk to each other, first, you know? And second, create quality. But I will say that there's the ideal situation there is sort of a size of the company that makes sense. I think that one thing people kind of discount is that the best practices for a very small company are different than the best practices for a large company, you know? If you're like a small company, and you're trying to scale, you know, you wanna get started first. You wanna create an MVP, you wanna -- and so the best practices for doing that are not necessarily focused on quality as much as they are vetting and validating your idea. And validating that it has a market, and validating that people want to use it. And that maybe creates incentives that are different. And if you're like a series a company where you have maybe 10, 20 people, and you have some investment, and you have some ability to take risks to improve quality, right? So, I think, the ideal situation is a little larger company — also larger companies — have the ability to onboard juniors more. I think that, you know, it -- it's tough when you're a small company to have maybe one developer who, you know, is a junior developer. I think it's probably great from a standpoint to that junior developer, they learned so much. I've been in that situation where I'm the only front-end developer or something, and I was kind of junior. And I learned a lot, you know? So, I think, it's great for the person. But for the company, maybe it's like they wanna move faster. They wanna- they wanna break things, but, like, they don't wanna things to be broken constantly. So yeah, you know, I think that the best practices are different. And the ideal situation is maybe a slightly larger company where there is a team. The team is sort of established. There's investment and ability to take risks. I would love to work with, you know, smaller companies and work from the beginning, right? But that also is maybe they may- maybe a little more dependent on me, right? They actually may wanna hire me as like a senior developer, and that's not really what I'm trying to do. I wanna come in, and, like, have a team that I can work with, and kind of affect, especially a junior team. So yeah, I think that I would love to be there from the beginning and help them build quality, but I'd rather be there when they are ready to build quality.

Bekah:

Hm.

Ryan:

Ready to- to have those counterintuitive solutions. Like, "Hey," you know, "Slow down. Don't -- when there's a- when there's tech debt, solve it right away. Have everybody work on it," you know? Things like this, which are sort of like, not the incentives you usually have. You know, cuz the main thing is they've been trying things. Like you said, there's a problem, right? Their -- the CTO is talking to the CEO, and the CEO is like, "Hey, you're not delivering on these business needs. Your team is making a- a qual- a qua- product that lacks in quality, and our users noticed." And, you know, what's the problem that you're -- you can't af- affect these things. That's kind of the- the issue that I would come in and sort of solve, is like when that exists -- and I think it exists in a lot of teams at different times. But yeah, that's what I would say. It's like there is an ideal size and an ideal problem to come in and solve, and- and not -- companies are not really ready for counterintuitive solutions when they're -- everything's working fine [chuckles]. I think they don't wanna come in and, like, change things. They're like, "Oh, everything's working fine." But when there's a problem, it's like, "Try something different. Try a different tact. Because that's how you're gonna find a solution."

Dan:

I -- you know, we talked -- Ryan had me on his Twitter space ... what was that? Last week? This week? I dunno. Time has no meaning anymore.

Ryan:

In the past.

Dan:

Recently? [All laugh] And-

Ryan:

Not- not in the future. In the past.

Dan:

One- one of the things we talked about wa- a lot was- was the idea of technical debt on teams, right? And- and that's like one of the- one of the -- maybe one of the problems that you are hoping to be able to help solve, right, with- with these teams.

Ryan:

Yeah.

Dan:

Could you talk a little bit about what- what technical debt is? You know, like, what- what it means to you when somebody says technical debt? And what -- and then- and then also, like, you know, how- how that can, like, negatively affect a team, you know? Maybe even without them knowing about it.

Ryan:

Well, I think there's actually -- it's important to say there's actually lots of different kinds of debt. They are different than just -- I mean, a lot of people when- when they say technical debt, they think of some developer experience problem where it's like there's something counterintuitive-

Dan:

Mm-hmm.

Ryan:

in the code, some feature -- but you know -- excuse me. There's actually multiple different kinds of debt. There's quality debt, which is where you're building things kind of let -- lack quality, and you just leave it that way. I did this funny tweet where I had a bridge that I built in like Poly Bridge — I dunno if you know this game — but it has these gaps in the bridge, and like, the truck goes across it, and the bridge flexes around, and I'm like, this is kind of how we built products. We leave these gaps and we say, "Oh, the bri- the truck can get across the bridge without the- the whole thing being built, therefore it's done." And so I think, that's sort of a quality problem, right? So that's quality debt. There's knowledge debt, which is where the- the- the product doesn't teach people how to use it, how to develop on it rather. And I think that the ultimate sort of product is one that teaches the developers how to- how to- how to create, you know, changes in it, right? How to extend it, how to modify it to maintain it. If the product isn't teaching people that, that's knowledge debt, right? That's sort of -- and the team isn't sharing the knowledge too, right? But -- so it's kind of a combination of sort of like automated solutions and just plain old interfacing with other people face to face, or- or you know, remotely. Or even asynchronously, right? Cuz there's lots of different ways teams operate these days. So, that's knowledge debt. There's tactical debt, which is, well, you know, we talked about, sort of like developer facing problems in the code that make it hard to develop, that make it hard to implement quality, and hard to share knowledge. And then there's- there's one other one that I- I can't think of right now [laughs]. But yeah, it's -- there's -- that's what I would say. There's lot -- there's other different kinds of debt. Quality debt, knowledge debt, technic- well, you know, I'll think of it. It's just funny. I should know it cuz it's kind of something -- I dunno if it's something I came up with, but it's something I talk about a lot. But there's different kinds of -- oh, innovation debt. That's it. So innovation debt is like, is things you wanna do but you haven't done, cuz you can't do it for some reason, you know? Like, you wanna build this feature, you wanna implement this big change, refactor the product, but everything else is holding you back, right? So, that's sort of like there's a debt in the- in the innovation you're trying to do. So yeah, I think breaking it down in different -- into different kinds of debt, not just focusing on calling it technical debt, sort of like opens you up to really affect the problems that are holding you back, to affect the things that are preventing you from delivering on that qua- promise, like I said, and quality, right? And promise of timelines ... you know?

Bekah:

Yeah, I love how you break that down. I think that that really helps to better understand what- what problems that you're facing, and also to be able to explain it to other people. Especially if you have junior members who are- are just coming into the industry and trying to understand exactly what you mean by technical debt. I think it also can help people to better identify their problems by looking at it in that way. So I- I think that this kind of touches on this idea of knowledge sharing and how you do that in teams. So, can you first define knowledge sharing for us? And then maybe talk about where to start with that?

Ryan:

Yeah, I mean, I think it's, you know, we have this problem of droughts these days, right? Because of, you know, global warming. And there's places that have water, there's places that don't have water. And how do you irrigate, you know? How do you get water from one place to another so that everybody can drink, everybody can grow crops, right? And that's sort of what I see knowledge sharing as it is. There's people that have the context, have the understanding, and there's people that need that understanding, that need that context to affect their work. And it's like, how do you get the water from one place to another, you know? And, there's lots of different ways to do it, right? There's, you know, documentation -- cuz the thing is, there's asynchronous and synchronous knowledge sharing, right? Synchronous knowledge sharing is what we're doing right now. We're having a conversation in real time. I'm telling you -- you're asking me questions, I'm telling you something logical. I wouldn't call it an answer, right? Cuz there's lots of different answers. But I'm telling you personal answers about like how I think about problems. So that's like synchronous knowledge sharing. And I think that if you can do that, that's kind of the best way to do it. Yes, it costs two people's time. Which is kind of where people get caught up is like, "Oh, there's a big cost," you know, like pairing. There's a big cost with meetings, you know, or one-on-ones ideally. But you know, of course there's a cost, but it's like there's a huge benefit. It's not like two times -- two people is two times work, you know? And two times cost. It's like, maybe it's two times cost, but it's like there's a multiplication effect that happens when people share knowledge, both in terms of the our ability to execute, and also their ability to build quality, right? Cuz they know the edge cases. They know sort of the context they need to create best practices within the product. And then there's asynchronous knowledge sharing, which is around, like, it could be Slack, right? It could just be that's async sort of knowledge sharing. There's also documentation, right? I have a lot of ideas on documentation and kind of how to affect it and make it sort of useful for people. But yeah, that's what I would say. That's sort of knowledge sharing in a nutshell. It's like how do you irrigate this knowledge between different areas? The people that have it, the people that need it, and doing it synchronously and asynchronously, and sort of like being aware of the difference between the two. I don't know if it's make sense.

Dan:

I love that metaphor. No, it makes- it makes a ton of sense. I, you know, I just --

Ryan:

I have a lot of water-based metaphors for programming. So --

Dan:

Water-based metaphors. Alright. I like it. I'm- I'm a big fan of- I'm a big fan of- of [unintelligible].

Bekah:

Would you be a Water Bender?

Ryan:

No, I would be Bruce Lee. Like, you know, if you put water in a cup, it becomes the cup. You put water in a bottle, it becomes the bottle. That's sort of my thinking of water is that it's like, it's flexible and I like- I like that idea. It's a flexible-

Dan:

So --

Ryan:

-metaphor.

Dan:

Nevermind. I was just [laughs] -- I was gonna take this metaphor too far.

Ryan:

No, well, you know, I mean, it's great metaphor, so --

Dan:

Oh, I was trying to figure out what- what, like, Twitter would be if you're, you know, sharing if knowledge is- is [unintelligible], like --

Ryan:

Twitter is a rainstorm [Bekah laughs].

Dan:

It is a rainstorm or is like you -- like your Twitter account — not you — but like a person's Twitter account is like you standing there with a scorecard [laughs], right?

Ryan:

Exactly. You're just -- it's a fire hose. You're just-

Dan:

Right [laughs].

Ryan:

-blast in into a- into a chasm [laughs].

Dan:

Right. Right. Yeah. Maybe it hits the people.

Ryan:

And sometimes it splashes back at you. But that's, you know-

Dan:

Right?

Ryan:

-that's about it. I don't know. That's a good question.

Dan:

I- I like -- no, I mean, but- but going back to like what- [chuckles] what you were saying before, the- the -- that metaphor of the -- especially the -- you started this with the concept of droughts, right? And- and, I think -- I feel like that is a really powerful part of this metaphor is, you know, you have these droughts, right? And o-of knowledge and- and the -- yeah, yeah. And the- the lake of knowledge, like, you have the lake of knowledge sounds -- this is [unintelligible].

Ryan:

Yeah. With the drought, nothing grows, you know what I mean? Nothing is built.

Dan:

Right, right, right.

Ryan:

Nothing is active.

Dan:

Yeah. And --

Ryan:

People are so, you know-

Dan:

I- I guess --

Ryan:

-thirsty [chuckles].

Dan:

Yes. I think that's a great way of thinking about it. It's -- it can -- pretty awesome metaphor.

Ryan:

Kim Kardashian is like mow- watering her lawn at 200,000 gallons, you know? It's like, no- nobody else has the water. I don't know.

Dan:

Right. So that means she's the senior developer who doesn't talk to anybody and then --

Ryan:

Exactly. I mean, there are those people right there try to forge power, right?

Dan:

Absolutely. You know, a-and --

Ryan:

Try to [unintelligible] dragons, [unintelligible].

Dan:

And talked about -- dragons [laughs]. Yeah, we- we- we talked about -- or you talked about, you know, it -- some of this work being easier with larger teams or whatever, things like that. I feel like this happens a lot more often with smaller teams. May-maybe not more often, but it is a harder solve -- problem to solve, right, with a smaller team. Especially, like, long-term. So, I'm just talking about myself here [laughs]. So-

Ryan:

No, go ahead.

Dan:

-just like talk about -- but like, I've been working on-

Ryan:

I'm very interested in it.

Dan:

-some of these- some of these products for, like, your -- like ... I dunno. I've been working on one client for over 10 years, right? And I have a ton of knowledge just in my head about it. And, you know, I try to do docs and stuff, but it's like small team, right? So that means, mostly me, you know? And then, sometimes, like Bekah worked with me for a while, and- and- and I have somebody else working with me now, you know? And it's -- -there's all these -- there's all -- there's like deserts, right? Of- of- of not knowledge, right? I, you know, there's places where I've like, "This is gonna be confusing, so I'm gonna, like, write things down." But there's other places where, you know, either — well, for a million different reasons — there's, you know, nothing, right? And I guess I don't really have a point other than it's hard- it's hard problem. It can be a very hard problem to solve for teams of all sizes.

Ryan:

Yeah. Well, you know, what I would say, again, counterintuitive solutions, right? My way of keeping -- my way of saying keep docs up-to-date is don't try [chuckles], you know? Speaking of the water metaphor, it's a point in time thing.

Dan:

Talk --

Ryan:

There's -- well, go ahead. What were you gonna say?

Dan:

Talk more -- no, I was gonna say, talk more about this [chuckles]. That- that is -- I never heard somebody say that before, so I wanna hear what you say.

Ryan:

Well, I think there's some documentation that needs to be sort of evergreen, right? Like onboarding documentation. It sort of needs to be evergreen. READMEs need to be evergreen. But I think architectural documentation, with, like, diagrams, and like, how things work, I think it's- it's so tough to kind of keep that up to date because it's such a big sort of problem, you know? Like, how does the whole thing work? It's different from onboarding, which is like, how do you start the thing you don't know. But-

Dan:

Totally.

Ryan:

-architectural doc- go ahead.

Dan:

Oh, I was just saying totally. I was just agreeing with you. I'm sorry [chuckles].

Ryan:

Oh yeah, exactly. Documenta- or, you know, architectural documentation is so tough to kind of like take the whole product and put it -- boil it down into a little residue of knowledge. And so I think, you know, I really like the idea of architectural decision records, which is I see it like a blog, you know? You're keeping a blog of like all the changes you're making in the product, and it's point in time, and you don't update it. It's just like, this is the decision we made. And then if you- you -- and I think if you reference those in the code, right? And, you know, you have some anchor comments or something that like link to these different architectural records. And, you know, the architectural records supersede each other, they amend each other, they have linkages, sort of like hyper text, right? It's like they're all linked together. So it is very much like a blog that you're keeping of the decisions you make throughout the development of the product. And you're not trying to like go in and create sort of an omnibus like book that's constantly has new additions. You're creating blog posts that sort of like, you know, do the point in time thing. And that's much easier to kind of approach, especially as a small team. Because you don't -- you're not, like, constantly going back and trying to create evergreen, you know, an evergreen documentation. You're just writing these blog posts and leaving it, you know, as you go, as little breadcrumbs for someone to say, "Oh, this is how the product evolved." Also, you have sort of knowledge about how the product used to be. Which I think is also very important because sometimes you wanna go back, you know? Sometimes you wanna learn from the past, you wanna learn from like how things were done initially. And also it's just like, it explains things in a way that maybe just a present sort of evergreen documentation wouldn't. Cuz you say like, "Oh, this is why that was done." There's so many times when we go into a codebase and go, "Oh my God, this is horrible. I was just done this way." And the truth is always a reason. There's always a reason. I- I always try to tell people that when they're like, "Oh, I got this legacy codebase, and it's like, it's the worst. Like, I can't believe it. Who are these bad developers?" It's like, you know, they were you. Just in the past, working with problem, you know? They're not, like, bad developers. It's just they're working on deadlines, they're working on the context is different. And so, like, I think knowing that having empathy for those original sort of the ancestors of the codebase is sort of like important. And just that's kind of something you get from a decision record that you wouldn't get from, you know, like explanation of what -- how things are. And also it kind of -- it- it shows sort of alternate solutions that you might consider in the future — the decision record. If you- if you look at the- the- the kind- you know, the way they're written, it sometimes talks about alternate paths that could have been taken in the decision that was made, and that could be useful in the future. You might say, "Oh, you know, that's actually a way we could go with this, based on the current context. Let's go refactor that." And it's also in the code. There's context, you know? It's like -- and I think documentation and code is really the way to go, for all things. Cuz I think it's like when you separate it from the code, you lose the context of ... you lose context. And I think that's important to understanding how things work. But yeah, that's kind of my thinking. Again, counterintuitive solutions, it's like try something different. There's a thing called, like, Oblique Strategies, where it's like- it's like you just have a card, you pull it out, and it says, like, you know, "Dance around in a circle," and like, that's how you, like, cultivate your creativity. I think like thinking differently and trying different things than you would normally do or are normally done in the industry is sort of an -- if -- even if it doesn't work, it tells you something about how it might work, you know? It's an experiment that you're testing hypothesis and maybe it doesn't work, but like, you learn something new in the process. So- so -- there was a dog.

Dan:

Oh, man.

Ryan:

Yeah, that's what I- that's what I think. Yeah.

Dan:

I love that. I -- this architectural deci- decision records ... I was just looking it up.

Ryan:

Yeah, yeah.

Dan:

I found a couple -- I kind of found a couple blog posts [unintelligible].

Ryan:

It's like, adr.github.io. A-D-R --

Dan:

That's what I -- yeah. That's- that's what I'm on right now. And I- I like that concept a lot. I like to, you know, it's -- it becomes -- it -- and I, you know, I have- I have spoken about this before, but I have ADHD too, right? And it's like-

Ryan:

Oh, yeah. [Unintelligible].

Dan:

-the- the idea of like, "Oh, okay, I need docs," right? This is like the thing that pops in my head, right? Like, there's nothing here. I need docs. But then, like, what are, like, I -- it's just such a huge thing to try to-

Ryan:

Yeah.

Dan:

-do. Like you said, it's like writing a book, almost. And you know that, like, I mean, and then when you start thinking about it, you know it's going to be out of date immediately and -- oh my gosh. So now it's like huge chunk of work to begin with.

Ryan:

I know.

Dan:

And then, also huge annoying chunk of works, like, chunks of work, to keep-

Ryan:

Yeah.

Dan:

-it up to date. And it just seems impossible in my head sometimes, you know? I'm --

Ryan:

Well, you know, when I worked at Dropbox, just to be wi- the things that were wild, we had librarians [chuckles].

Dan:

Oh, man.

Ryan:

Technical librarians.

Bekah:

Whoa.

Dan:

Yeah, well, that's [unintelligible] --

Ryan:

Who's, like, literally --

Dan:

I mean, like, that --

Bekah:

Hey, that's I wanna be. A technical librarian [Dan laughs].

Ryan:

Yeah, I can connect them to you.

Bekah:

I didn't know that was a thing.

Ryan:

I can connect you to if you want.

Dan:

That sounds awesome. I mean, like, that's the kind of thing you- you -- the -- once your company grows in size, like, you know, you can start having people that have jobs of, you know, specific jobs, right? And in smaller teams, you have to do everything, right? And that's- that's a very cool. I- I wonder if there's some-

Ryan:

Once you get -- that's- that's a big [unintelligible].

Dan:

-I wonder if there's like a consulting -- technical librarians that can consult ... Well, I mean [unintelligible] --

Ryan:

Well, generally, there are technical --

Bekah:

That's really what I wanna do. I wanna be a-

Dan:

Yeah. I mean, like --

Bekah:

-consulting technical librarian.

Dan:

Right, right, right. So -- yeah.

Bekah:

You evaluate, you put the books back in the right order.

Ryan:

Yeah.

Dan:

Yeah, because like --

Bekah:

Say, you don't wanna miscategorized.

Dan:

Right. And then, keeping it up to date. Like, if you have somebody that is not a full-time employee, right? But somebody who's -- like, all right. The first run through would be a big project, right? But like, after that, it's like maintenance stuff. Maybe a couple hours -- whatever. A week or a month, you know, whatever it is. But like, that -- man, alright. I have to think this about this one. That sounds- that sounds awesome.

Ryan:

No, I- I agree. It's- it's- it's a- it's a huge task. And so, like, having specialized people is really valuable.

Dan:

Yeah. Yeah, yeah.

Ryan:

But, you know, also -- but they're -- they don't necessarily have the context. So they're just sort of like organizing, making sure things are formatted correctly, making sure things are-

Dan:

Right.

Ryan:

-linked correctly. But, you know, the knowledge has to come sort of ultimately from the people who are on the [unintelligible], you know?

Dan:

Totally. Totally. But if- but if somebody's like -- and that -- this is, like, you know, speaking of something that I've done that is not well documented or whatever, but somebody asks me a question about it, then I'm, like, can talk about it for a while. You know what I mean? But then-

Ryan:

Yeah.

Dan:

-and you mentioned, like sla- like those async, you know, learning channels and stuff like that. That's this kind of thing. And then -- but then it gets buried in a Slack, you know, thread somewhere and disappears cuz-

Ryan:

Oh, yeah.

Dan:

-we don't pay for Slack [laughs]. You know, and all that stuff, right?

Ryan:

Yeah [laughs].

Dan:

And so ... oh, man. I- I like the idea of having somebody, an outside person -- plus, like, if you see somebody do -- I'm sorry I'm talking about this so much. But I'm excited about it now [laughs].

Bekah:

No, that's fine.

Dan:

But if you- if you, like, if me, as- as, like, the ... whatever. A lead developer on a project, and you have an outside person that comes and gets something going or adds an addition, you'll be able to like -- I would be able to, like, see if it's wrong or needs some, like -- not wrong, but, you know, need some, like, tweaks or whatever. And that's an easier job than-

Ryan:

Well, there's a value to --

Dan:

-than starting from the- starting from the beginning [chuckles], right?

Ryan:

It's a value to an external perspective. That's what I always say about myself is like, you know, you've tried things, you have a context about how things work. I can come in as with an external perspective and provide additional value that you otherwise wouldn't get, you know?

Dan:

Totally.

Ryan:

It's kind of like -- I'm trying to think of an explanation. It's cross-pollination, you know what I mean? It's like you're getting sort of information or wi- genetic information from an external source. And that creates a better ... sort of, you know, better result. If you just kind of like, I don't wanna get into, like, genetics. But it's like, you know, you don't wanna just- just breed the same genes over and over again. It creates sort of problems. And so it's like you need that external information, external perspective. And, you know, I think every company needs that. And that's kinda what you get when you hire people, right?

Bekah:

Yeah.

Ryan:

You're hiring-

Dan:

Totally.

Ryan:

-someone, they come in with their own sort of knowledge, and abilities, and -- but, you know, if you can just -- you can also hire a consultant, you know? And they- and they can provide the same sort of thing on a more temporary sort of basis and less -- you know, ultimately, less cost, right? You know, than hiring somebody. But over- over, you know, if they come in for three months and you cost this much, hiring someone for a year and maybe not having them do the same work is, you know, a different- different calculus. But, yeah. External perspective is very valuable.

Dan:

I love that. You've given me a lot to think about [laughs].

Ryan:

Yeah. That's good.

Dan:

I mean, I'll- I'll -- every time we- every time we met --

Ryan:

We have to talk about it some more. Yeah.

Dan:

Yeah. I always- I always end up coming away with a- with a lot of stuff to think about. All of that.

Ryan:

Yeah. Well, that's the point, right? Is like -- that's the -- I have the external perspective, and you're learning from it. And I'm learning from yours. That's sort of the- the ultimate idea, right? Is like we learn from each other. That's why we have conversations. It's not to, like -- I'm not, like, telling you stuff. I wanna listen, you know?

Bekah:

Yeah. That's so important, that idea of listening. Cuz it's hard to do and so much of the time we spend listening to respond to other people rather than just listening to understand people. And I think, that's -- it's a hard thing to do, but it's a good habit to work on in- in any situation. But especially, if you're on a team of diverse people or-

Ryan:

Oh, yeah.

Bekah:

-I- I think, too-

Ryan:

Well, hopefully you are [laughs].

Bekah:

-if you're working remotely. It --

Ryan:

Yeah. I think that listening, it requires empathy, right? But it- it's more than that. I think it -- because empathy comes from letting go of yourself.

Bekah:

Mm-hmm.

Ryan:

You know, if you come into a listening situation without compassion, which is literally just like not putting yourself in the other person's shoes, but just not even- just not even really imagining, you know what I mean? You just kind of let go of your own preconceived notions and- and listen to the person. And then, when they're done, you come out of it and try to integrate it. Then you can come up with some advice. But if you're sitting there in your head sort of calculating like, "Oh, this is my answer. This is my answer. This is how I think about it. This is how," you know? Then you're not really listening. You're like, I don't know what it is, but you're not listening, you know? Listening is really like letting go of yourself for a moment, completely, as much as possible, and just being present with the other person. And really like trying to -- that's how empathy comes. It's not from, like, relating it to your experience, your own sort of hurts, and desires, and, you know, suffering or whatever you wanna put it, you know? In the Buddhist sense I would say. But yeah, you know, it's really just kind of listening and being there for the other person. And then, after they're done, you come back, and you go, "Wow," you know, "I really learn from that perspective," you know? Cuz it's -- ultimately, listening is learning, right? And the way you learn is not by -- is by integrating, but first, sort of, you know, transporting yourself to another- another way of being in other perspective.

Bekah:

Yeah. I love that. Well, Ryan, it's about time for us to wrap up. Is-

Ryan:

Yeah.

Bekah:

-there one tip that you can leave our listeners with, to help them get started in this idea of building better teams through empathy and listening?

Ryan:

Wow. That's a good question. I think it's being, you know, compassion is very important. There's a big push these days for compassionate coding, for compassionate teams. And you know, I've been on some teams as well that just don't -- there's some lack of disconnected compassion, you know? And so being gentle with each other, being empathetic as you said, is such an important skill and such an important, you know, component of being a team. That listening aspect of really kind of letting go of yourself and connecting with another person is -- you know, and then- and then sharing knowledge, you know, is, like, that's- that's -- the- the basis of sharing knowledge is connecting with the other person's experience. You're just talking at them and saying, "Read the docs," you know? Like, that's not how you connect with the person, and then connect -- because ultimately, the knowledge, as I said, is, like, about connecting some sort of theory to your personal experience, you know? That's how you transfer knowledge, is I tell you, this is my experience. Or you tell me first. I think you have to ask questions first, you know? Ask questions first, and listen. And then see -- you say, "This is my experience." Then I go, "Oh," you know, "based on what I think, this is how I might connect with what you said. This is how I might connect with you as a person." So, I don't know if that makes sense to your question, but that's what I would say, is being gentle, being compassionate first. And not trying to just kind of grind people, you know? Cuz that's really how you lose your team. It's how you lose kind of the knowledge that people have when they leave is you burn them out. And you're not being compassionate. And I think it's so tough on a corporate level to be compassionate cuz there's the profit motive, and business needs, and all this stuff. But if you can really kind of let that go and say, "Look, we're gonna care about our people first," that will reap the rewards, you know? That'll reap the rewards more than like, you know, burning people out for a business end, you know what I mean? Like, there's more to life. You're a person too. The CEO's a person, you know? They don't wanna -- they wanna go golfing or whatever. They don't wanna, like, you know, just be burning themselves out and, you know, to like, to- to- to make money, I think, ultimately. Maybe they do. But that's sort of my opinion, is like, you wanna build a great team, be compassionate. And play golf, I guess, you know? Let them play golf. I don't know what do they wanna do [Bekah and Dan chuckle]. I play disc golf. But, you know-

Dan:

Yes!

Ryan:

-let people be themselves. And I think, that's -- you also have to accept that people don't work the same hours, people don't have the same accommodations. Like, that's where com- that's where compassion comes in, is like understanding the diversity of people and trying to make them productive and not trying to put them on a clock, and like- like, where, you know, in the- in the Henry Ford factory, it's creative work. You really need to kind of disconnect from that idea of, like, you know, hours, and time, and productivity.

Bekah:

Wow. That was a great way to end the episode.

Dan:

Yeah. Amazing.

Bekah:

Thank you so much, Ryan.

Dan:

Thanks, Ryan. Thanks for coming on.

Ryan:

Of course. It's so wonderful to talk to you both, the two people I really respect, and have great connection with, and it's so nice to be able to spend time with you. And, you know, I guess recorded, but ... just to-

Dan:

Yeah, sure.

Ryan:

-spend time with you is really nice.

Bekah:

Yeah.

Dan:

Yeah. Agreed. Alright. Yeah, we'll talk to you later.

Bekah:

Thank you.

Ryan:

Oh, you talk to me now [Ryan and Bekah laugh].

Dan:

Oh, and also later.

Ryan:

And also later. Yeah. I love you, guys.

Dan:

Alright.

Bekah:

Bye.

Dan:

Bye, Ryan. Thank you for listening to this episode of the Virtual Coffee Podcast. This episode was produced by Dan Ott and Bekah Hawrot Weigel. If you have questions or comments, you can hit us up on Twitter at VirtualCoffeeIO, or email us at podcast@virtualcoffee.io. You can find the show notes, sign up for the newsletter, check out any of our other resources on our website, virtualcoffee.io. If you're interested in sponsoring Virtual Coffee, you can find out more information on our website at virtualcoffee.io/sponsorship. Please subscribe to our podcast, and be sure to leave us a review. Thanks for listening, and we'll see you next week!

The Virtual Coffee Podcast is produced by Dan Ott and Bekah Hawrot Weigel and edited by Dan Ott.