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:

Hello and welcome to season six, episode seven 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:

What Wuddup Bek? How's it going?

Bekah:

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

Dan:

It's going okay. Um, yeah, we have a great episode today. We met with Ryan Con, uh, who has done a lot of things through his career. He was a teacher, he's a developer, and, uh, 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, uh, Ryan's, I mean, Ryan's always great to talk to you. Um, and yeah, and that, that, like, that, that philosophy, I think, uh, I don't know, lines up a lot with a lot of the stuff we talk about here at Virtual Coffee. So, um, it was nice to hear him talk about it, and it's nice that he is, uh, he's doing this, like he's, I was very interested to hear about his consultancy, um, and his like, sort of new journey that he is doing because, uh, it's a little bit of a different approach than, you know, most people, I'm, I'm a consultant myself, but I just kind of come in. Do like the work, right? Or like, you know, the kind of stuff you, you think about, right? And this is more, um, Ryan's gonna come in and help teams, uh, improve their whole situation, right? And then leave you know? And I think that's really great. I think it's a, I think it's a very cool thing to do. Um, and I was excited to hear about it.

Bekah:

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 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 only ones I wanna get rid of. The ones without agendas. Those ones.

Dan:

Sure.

Ryan:

one.

Dan:

Yeah. Well, this isn't a meeting, this is, this isn't an event,

Bekah:

Mm-hmm. this is an event.

Dan:

Uh, alright. Hi, I'm Dan. I am in Cleveland. I do website development. And, um, 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 a three old and a six 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 cause 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, and 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 trying to get them buckled and all this stuff. So that's gonna be my answer. Yeah. Putting the kids in the car, they could just like snap and they would just be strapp in the car.

Bekah:

with their shoes on too, right?

Dan:

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

Bekah:

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 didn't bring any shoes. Like, Why? What? How is thing? 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:

Um, standard operating procedure. Okay, well, I'm Ryan. I am a, uh, developer, experience consultant and productivity consultant in New York City. A little, little town in New York called New York City. Um, 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. Um, and yeah, meetings, Uh, I actually like meetings. I think that that's when I do my best work. So I won't say that. I will say, That is the one thing that my wife and I have the most tension about is actually just doing the dishes. Cause neither one of us likes to do it. Um, so I would remove that from my day in a heartbeat. Uh, 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. Um, yeah.

Dan:

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, know, I, chores are like a paint, I don't mean easy, like easy to get myself to do, you know? Um, I think I can listen to podcasts and stuff, and so it's, I don't know.

Ryan:

Yeah. It's rather meditative

Dan:

when I'm doing the dishes. Yeah, exactly. Exactly. Like if I'm doing that chore, then, you know, every. Somebody else is dealing with the kids

Ryan:

Hmm. A little break.

Dan:

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

Ryan:

Oh,

Dan:

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

Ryan:

Our dishwasher's actually broken right now, 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. 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.

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. Um, 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 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, uh, 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. Um, but yeah, I never considered it as a career. You know, I had a teacher in high school who got me into economics. Um, 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. Cause 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. And, uh, 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, 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 J Query and stuff like that. This was back in 2009. And uh, 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. Um, 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. Um, 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, um, 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. Um, but I learned a lot at that job. I worked with a lot of great engineers, um, learned a lot about what I didn't want in a job. Um, and at the same time, I, uh, I went to a meetup for general Assembly and they asked me, Someone just came up and said, Hey, do you wanna be a teacher? And I immediately said, yes. Um, 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, uh, yeah, so I, I did some teaching, a general assembly, and that was sort of the end of my programming career, even though it lasted for another seven years or something. Um, Actually, I don't know how long, but it lasted for a long time after that, uh, even though I decide, I decided at that point that I wanted to solve human problems, um, in software and not so much solve the, the programming problems, but I kept grinding at it for many years. Moved to New York. Uh, it's continued to teach at a company called Thankful. Um, just worked at Squarespace first and then Dropbox, and then eventually just, you know, kind of burnt out on development. Uh, cuz again, I, I kind of had already found something in my calling a little bit, uh, in something else related. And so now I work as a consultant. Um, 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, uh, and. Deliver kind of on a promise of quality, you know, and, and, and timelines. Uh, so that's what I'm trying to do as a consultant. But that was sort of an evolution from teaching, uh, 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. Um, and that's been a source of great joy for me. Uh, 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.

Dan:

We're the, we're the best one, obviously, so

Ryan:

Well, the most welcoming right 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, uh, 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 really

Ryan:

Yeah. I invited ahead.

Dan:

ahead. I was just gonna say thank you for that story, but.

Ryan:

Yeah. Okay. Sure. Yeah. Yeah. It's, it's, uh, it's a story that, um, 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:

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 want to do. Right in the beginning. You know, I taught htm, I taught a front end course, a 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 want to 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 startupy. 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, um, 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. Um, 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, um, 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. Um, 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. Um, 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,

Dan:

Yeah, that's, that's really cool. I was, I was, I think that's actually the answer, but I was gonna ask, um, you know, you talked when you were talking about, um, before you were teaching, um, that feeling, right, the feeling fixing the game or, uh, adding the ClickHandler, right? You were talking about staying close to that feeling, which I, which is, 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, uh, 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. 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, um, or if you've thought about that at all, how you stay close to that Um,

Ryan:

I think it all the time actually.

Dan:

Yeah.

Ryan:

Um, well, for me it's the concept, you know, uh, 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 the experts mind. There are a few. Um, 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. Um, it's, you know, it's like, it's some new combination, some new context, some new, uh, outcome you're trying to achieve. Some new technologies. So I try to stay close to beginner's mind as much as I can by reminding myself that I don't know, and, uh, 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. Um, 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. Um, and the reason for that is that helps me stay close to beginner's mind by working with beginners. Um, you see the kind of endless possibilities in their mind. Um, 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. Um, 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 type script compiler says, Go ahead. Um, 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. Um, second.

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 before I ask this question. Yeah, yeah. Totally. Totally. You know, and you had, you had started talking about um, how you like doing more one on one, you know, pairing stuff like that, um, with people, and I imagine that's, it becomes a lot easier to do that right. 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. Um, to,

Ryan:

Also I've found that. Exactly. And also I've found that, I mean this is an a d d 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 And so like that's why freelancing

Dan:

about that.

Ryan:

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 pair programming or. If, 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 a 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. Um, 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? Cause I was so used to seeing, you know, to to telling people I was a software engineer. I still do sometimes cause 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. Somebody doesn't know the difference anyway. Uh, 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 kind of know what their individual problems are. You have to talk to them. Um, 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. Um, so yeah, I think that, uh, yeah, knowing, knowing people, knowing the people on the team is kind of the most important thing. And being personal, um, you know, I don't, I'm not writing a book, right. 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, um, to do better. Uh, 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.

Bekah:

Yeah. Well, I mean, it's a hard balance transitioning from doing like one on one mentorship and teaching 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. Um, 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?

Ryan:

Well, you know, I, I think there's, I have sort of a view on learning. I mean, I have a lot of soundbites, right, that I say over and over again. But, um, you know, my view on learning is that, And 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. And it's very multidimensional. It doesn't overlap with other people. It's centered around you. Um, 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, um, like you know, in the military or something where everybody just sort of like follows an, I mean, I don't know, I never 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. Trying to break that cycle and improve kind of pairing and knowledge sharing between the team. Because a lot of times, I mean, 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. Teams working together. And so I think the, the ultimate thing is I don't wanna be there long term, you know, I'm not there to like be the teacher forever. I, 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. Um, 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. make myself not necessary in the long term. Cuz again, I wanna work in limited engagements. It's again, an a, d, D 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 do the, do the judo move where you just sort of like come in and flip things around and leave, you know, Um, that's kind of my ultimate. Is not to, not to be, to make people dependent on you, 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. Um, I don't know what the right word is. Uh, what would you, what did you say?

Ryan:

Uh, Dynamics.

Bekah:

dynamics. You know, people wait until there's a problem and I feel like bringing someone in very early on can reduce miscommunications, burn out. Um, 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 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? Um, 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. Um, 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. 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. Um, 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. Um, 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. Um, I would love to work with, you know, smaller companies and work from the beginning. Right. But that also is maybe they may, may be 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 want to come in and like have a team that I can work with and kind of affect, especially a junior team. Um, 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. Um, 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. 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 qu product that lacks in quality in our users notice, and you know, what's the problem that you're, you can't 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. Um, 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. I think they don't want to 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:

know, we talked, Ryan had me on his Twitter space. What was that last week? This week? I don't know.

Ryan:

Um, the past

Dan:

Recently, And,

Ryan:

not future,

Dan:

one of the things we talked about was a lot was, um, 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. 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, um, a team, you know, maybe even without them knowing about.

Ryan:

Well, I think there's actually, it's important to say there's actually lots of different kinds of debt. That are different than just, I mean, a lot of people when they say technical debt, they think of some developer experience problem where it's like there's something counterintuitive code. Um, 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, the truck can get across the bridge without the, the whole thing being built, therefore it's done. And um, so I think that's sort of a quality problem, right? So that's quality debt. There's knowledge. Which is where the, the, the product doesn't teach people how to use it, how to develop on it rather. Um, and I think that the ultimate sort of product is one that teaches the developers how to, how to, how to create. 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 you know, remotely or even asynchronously, right? Cause there's lots of different ways teams operate these days. So that's knowledge debt. There's tactical debt, which is, you know, what 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, hard to share knowledge. Um, and then there's, there's one other one that I, I can't think of right now, but yeah, it's, there's, that's what I would say. There's lot, there's other different kinds of debt. Um, quality debt, knowledge, debt, technical debt. Well, you know, I'll think of it. Um, 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, um, Oh, innovation debt. That's it. So innovation debt is like, Is, um, 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 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 promise, like I said, and quality right, and promise of timelines. Yeah.

Bekah:

I love how you break that down. I think that that really helps to better understand what, what problems that you're facing, um, 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. Um, so I, I think that this kind of touches on this idea of knowledge sharing and how you do that in teams. So, um, 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, uh, you know, we have this problem of droughts these days. 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 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? And, uh, there's lots of different ways to do it, right? There's, you know, documentation. Cause 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. Um, 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, Um, or one on ones ideal. Um, 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. 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, uh, 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, uh, doing it synchronously and asynchronously and sort of like being aware of the difference between.

Dan:

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

Ryan:

I have a lot of water based metaphors for programming.

Dan:

water-based metaphors, All right. I I'm, a big fan of, I'm a big fan of, uh, of Data's

Bekah:

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:

nevermind. I was just I was gonna take this metaphor too far.

Ryan:

No, well, you know, 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

Ryan:

Twitter is a rainstorm.

Dan:

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. right.

Ryan:

You're just, it's a fire You're

Dan:

That's right.

Ryan:

a, Into a chasm.

Dan:

Right, right. Yeah. Maybe it hits

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 you were saying before, the, the, that metaphor of the, especially the, uh, you started this with the, uh, concept of droughts. Right. And, um, and I think, I feel like that is a really powerful part of this metaphor is. You have these droughts, Right? And of knowledge and, and yeah. Yeah. And the, the lake of knowledge, like you have the lake sounds, This is

Ryan:

A drought, nothing grows, what I mean? Nothing is

Dan:

Right, right, right. Yeah. And

Ryan:

People are, you know,

Dan:

I think

Ryan:

thirsty.

Dan:

yes, I think that's a great way of thinking about it. Uh, it's,

Ryan:

Kim Kardashian is like 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

Ryan:

exactly. I there are those people right there

Dan:

absolutely. You know, and,

Ryan:

knowledge Dragons,

Dan:

and talked about, Yeah, we, we, we talked about, uh, or you talked about, um, you know, Some of this work being easier with larger teams or whatever, things like that. Um, I feel like this happens a lot more often with smaller teams. Uh, maybe not more often, but it is a harder solve problem to solve, right? With a smaller team. Um, especially like long term. So I'm just talking about myself here, So just like talk about, but like, I've been working on some of these, some of these products for, um, like your. Uh, I don't know. 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, um, 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, 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, um, I guess I don't really have a point other than it's hard. It's our problem. It can be a very hard problem to solve for teams all size.

Ryan:

you know what? I would say again, counterintuitive solutions, right? Um, My way of keeping, my way of saying keep docs up to date is don't try You know, speaking of the water metaphor, it's a point in time thing. There's, Well, go ahead. What were you gonna

Dan:

talk more. No, I was gonna say, talk more about this. That is, never heard somebody say that before, so I wanna hear what you

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. Read means 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, um, architectural, Go ahead.

Dan:

Oh, I was just saying totally. I was just

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. You don't update it. It's just like, this is the decision we made. And then if you, you, I think if you reference those in the code, right, 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. 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, uh, 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 code base 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 always try to tell people that when they're like, Oh, I got this legacy code base, 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 problems, 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 code base 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 shows sort of alternate solutions that you might consider in the future. The decision record. If you, if you look at the, the, the, 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. And it's also in the code. There's context, you know, it's like, um, and I think documentation and code is really the way to go, um, for all things. Cuz I think it's like when you separate it from the code, you lose the context of, um, 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 o bleak strategies where it's like, it's like you just have a card, you pull it out and it says like, 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 I was a dog Yeah, that's what I, that's what I think.

Dan:

I love that I, this architectural decision records, um, I was just looking it up. Uh, I found a couple, I kind of found a couple blog

Ryan:

It's like adr GitHub dot. I owe

Dan:

that's what I, Yeah, that's, that's what I'm on right now. Um, and I, I like that concept a lot. I like to, you know, it's, it becomes, and I, you know, I have, I have spoken about this before, but I have ADHD too, right? And it's like, um, 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, it's just such a huge thing to try to 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. And then also huge annoying chunk of works, like chunks of work, uh, to keep it up to date. And it just seems impossible in my head sometimes, you know?

Ryan:

Well, you know, when I worked at Dropbox, just to be the things wild, we had librarians, technical librarians who li I mean literal

Dan:

like that

Bekah:

I wanna be a technical librarian. didn't know that was a thing.

Ryan:

can connect if you want.

Dan:

uh, 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 smaller teams, you have to do everything right. Um, and that's, that's a very cool I wonder

Ryan:

you get, that's a big

Dan:

if there's like a consulting. Technical librarians that can consult

Ryan:

Well, there are technical writer

Bekah:

what I wanna do. I wanna

Dan:

Yeah. I mean like

Bekah:

librarian.

Dan:

Right, right, right. So,

Bekah:

you put the books back in the right order,

Dan:

Yeah, because like,

Bekah:

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, uh, run through would be. 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.

Ryan:

No, I, I agree. It's, it's, uh, it's a, it's a huge task and so like having specialized people is really valuable, but, you know, also, but they're, they don't necessarily have the context, so they're just sort of, Organizing, making sure things are formatted correctly, making sure things are linked correctly. But you know, the knowledge has to come sort of ultimately from the people who are on the you know?

Dan:

But, but if somebody's like, and that this is like, you know, speaking of something that I've done that is not well documented, 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, and you mentioned like, 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 don't pay for slack you know, and all that stuff. Right? And so, um, 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, But if you, if like, if me as, as like the whatever 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

Dan:

the, starting from the beginning. 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, it's kind of like, uh, 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 genetic information from an external source, and that creates a. 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 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 kind of what you get when you hire people, right? You're hiring someone, they come in with their own sort of knowledge and abilities and, uh, but you know, if you can just, you can also hire a consultant, you know, and, and they can provide the same sort of thing on a more temporary sort. Basis and less, you know, ultimately less cost. Right. You know, than hiring somebody. But, uh, 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 perspectives very valuable.

Dan:

I love that. You've given me a lot to think about I mean, I'll, I'll Every time we, every time

Ryan:

have 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.

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.

Bekah:

that's so important. Um, 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 I, I think too,

Ryan:

Well, hopefully you are 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:

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 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, is 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 way of being, another perspective.

Bekah:

Yeah. I love that. Well, Ryan, it's about time for us to wrap up. Is there one tip that you can leave our listeners with to help them get started and this idea of build. Better teams through, um, empathy and listening.

Ryan:

Wow. That's a good question. Um, 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. Component of being a team. That listing 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 a person and connect because ultimately 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 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. See, I don't know if that makes sense to your question, but that's what I would say is being gentle, being compassionate first. 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. 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 want to, 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 whether they were, they. I play disc golf, but, you know, 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, 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 Henry Ford factory, um, it's creative work. You really need to kind of disconnect from that idea of like, you know, hours and time and productivity.

Bekah:

was a great way to end the episode. Thank you so much, Ryan.

Dan:

Thanks, Ryan. Thanks for.

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 record it, but just to spend you is really

Bekah:

Yeah.

Dan:

Yeah, Agreed. All right. Um, yeah, we'll talk to you later.

Bekah:

Thank you

Ryan:

Oh, you talk to me now,

Dan:

and also later,

Ryan:

and also later. Yeah. Love you

Dan:

right. 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.