Season 9 Episode 4 Jun 1, 2022

Getting Along with Your Co-workers... All of Them


"Maybe you don't get to use your favorite tool, but that shouldn't be the goal, you should use the thing that works for both of you."


In this episode, we talk about how to work cohesively and efficiently across different departments with Kate Travers, Senior Software Engineer at GitHub, and Tracy Osborn, Principal Program Director at TinySeed.


Ben Halpern

Forem - Co-founder

Ben Halpern is co-founder and webmaster of DEV/Forem.


Kate Travers

GitHub - Senior Software Engineer

Kate Travers is a New York-based web developer specializing in Rails, React, and Elixir applications. Before changing careers to ship code, she spent five years shipping fine art for the world's finest museums, galleries, and private collectors. She currently works at GitHub on the Pull Requests team.

Tracy Osborn

TinySeed - Principal Program Director

Tracy Osborn is the author of Hello Web Design (No Starch Press) and Program Director at TinySeed, a startup accelerator and venture fund aimed at bootstrappers.

Show Notes

Audio file size





[00:00:00] TO: I find a lot of managers struggle with those things because they’re like, “It’s taking away time for what you’re working on.” It’s like, “Are you being productive right now?” But that’s like the easiest way to just kind of allow those kinds of communication channels when you’re working on a fully remote team.


[00:00:24] BH: Welcome to DevDiscuss, the show where we cover the burning topics that impact all of our lives as developers. I’m Ben Halpern, a co-founder of Forem. And today, we are talking about how to work cohesively and efficiently across different departments within your organization with Kate Travers, Senior Software Engineer at GitHub, and Tracy Osborn, Principal Program Director at TinySeed. Thank you so much both of you for being here.


[00:00:49] TO: Yeah. Happy to be here.


[00:00:51] KT: Yes, likewise. Thank you.


[00:00:52] BH: So we brought both of you here because you are both talented in what you do and we are excited to pick your brains about working cross departmentally. But before we get into all of that, can we get a bit about your career background? Katie, how about we start with you?


[00:01:08] KT: I started my career in the art world, which Tracy, I think we have that in common. So yeah, that’s what I went to school for. I have a degree in art history. And so after college, when I moved to New York, I was working in museums. I eventually ended up in a world of fine art shipping. So I found a niche and then an even smaller niche, but that was actually what introduced me to kind of working with… that was my first time working with software teams directly. We had hired some contractors to build software. I volunteered as kind of their in-house expert, their stakeholder, ended up joining the team as a QA and a support engineer and kind of never looked back, went to a coding bootcamp, changed careers, and I’ve been working as an engineer full-time ever since.


[00:01:49] TO: My degree is in graphic design. Technically, it’s art and design. So I did a whole bunch of studio classes back in the day and thought I was going to become a product designer. I ended up in the startup world and largely never left. This was about 20 years ago. So I worked at a startup. We literally started in a garage, down the street from my university. I ended up leaving them about four and a half years later. Started my own startup, worked on that on and off for about eight or so years, hoping to get to some level of success. That never materialized and I ended up shutting it down. And during that time, I taught myself how to code for that startup. There’s a brief period of time during that time I was working on that startup when I thought I was going to put off this side and I got a job at another company. That lasted about four months as a developer advocate before I was laid off and I went back to my own thing. And then about three years ago, I shut down my startup and I joined TinySeed, which is an accelerator for bootstrap companies as their program director. So I wear a lot of different hats. I guess I’ve taught myself how to code. My background is in design, did a lot of stuff with sales and marketing, whatnot. So kind of always been in and always worked with smaller companies with folks like me that kind of wear a lot of hats as well.


[00:03:01] BH: So I think both of you have a lot of similar experiences, but also a lot of different experiences. We’re going to be talking about some of the fundamental stuff here, when it comes to big organizations and smaller organizations. We’ll find out what might actually maybe be different in those different environments, but also what’s the same no matter what. Katie, you’ve done a lot of work teaching folks how to work with technical teams and you wrote a post on DEV and titled How To Work With Developers - A Guide for Non-Developers. Can you talk about what led to writing that?


[00:03:36] KT: That was actually something when I was an apprentice developer, my very first job. I was volunteering with an organization that was working with college students primarily who were about to head out and enter the startup world. These were very entrepreneurial minded students. And so I was asked as a volunteer. They’re like, “Kate, this is going to be their first time kind of out there working at a startup, living that startup life. Can you tell them a little bit about what to expect?” Which is a very big ask. And so initially, I wasn’t really sure what was going to be important for me personally to communicate to them. But yeah, the angle that I came up with though is I just wanted to share what I had, what do you kind of notice and experience so far in my own life of kind of moving from one side of that company, the non-developer side of the company, to being part of that engineering team and offering a perspective of what it’s like to work on, either sides of what had been a noticeable divide in my experience, at least. So yeah. And that post kind of came together first and then I’ve developed it into a talk and actually I’ve given it for a couple of summers in a row at this point. And the advice still applies. I’m relieved because it’s still pretty applicable.


[00:04:49] BH: You had a sub header titled, “Developers That Are Just Like Us or Are They?” Can you dig into what you got into there? What’s the answer?


[00:05:01] KT: Yeah. Well, in this one, it’s interesting. Like I’ve said, I’ve got a lot of feedback on this over the years. And now I’m waffly, what I give it, I kind of say yes and no. But I mean, at the end of the day, I don’t know. I think we are. I think engineers are kind of… we’re funny, just like any other very specialized kind of role. We’re funny. We’re our own thing. So like any department, I think that this applies to pretty much any role that you’re going to meet in the tech world. We’re different. Different types are drawn.


[00:05:31] TO: Yeah. Every single department is going to have their own quirks and weirdness. I guess that’s one of the reasons why we’re having this discussion because when you’re in your little bubble, your departments, you have these ways of communicating and these norms and things that are normal for your department. And then every single department is going to have their different rules and norms of whatnot. And just as engineers will have their own way of thinking, so does the design department. Everyone, I guess, there are these little bubbles and it’s kind of hard to communicate between them because there’s like different communication styles.


[00:06:05] KT: Yeah, totally. I think bubbles is a fantastic way of describing it. I was kind of hemming and hawing because I want to be cautious about speaking in generalities and there are all those stereotypes out there about, whatever, engineers, designers, et cetera. But yeah, it’s bubbles, right? Like you get used to working in a specific type of way and communicating a certain type of way and that isn’t necessarily or more likely than not. It’s not going to be the same. It’s not going to be shared across the company, unless you’re at a company that’s actively working to bring those communication styles closer together.


[00:06:38] BH: So Tracy, you actually have a DEV post titled “Design for Non-Designers”, which is a very similar vein, and we’re talking about department bubbles in general. Can you talk about that piece and what some of the main takeaways were?


[00:06:52] TO: Yeah. I wrote, actually, well, better way to say is I’ve always been interested in skills for folks in one department and what they can learn to get just dangerous enough or just skilled enough that they can help out or understand the language or take on those skills themselves. So the Design for Non-Designers is for folks who are not designers and so engineers or marketers or founders or anyone who doesn’t identify as a designer. What are the things that you can learn about design so you feel comfortable launching your own landing pages or creating your own widgets or creating your own forms, kind of understanding the deeper principles in those things without necessarily having to jump into a design career? So I feel really passionate that we all need to specialize, especially in larger organizations, your specializations get deeper and deeper, but to have these additional set of skills that might not be in your specialization, be that design or even understanding what’s going on in the marketing side of things, what’s going on in the sales side of things, it’s going to make you stronger in your own specialization. So as an engineer, stepping away from the design side of things, as an engineer, knowing the way that the people on the sales team kind of talk about or how they sell the product, and then when you’re building things for that sales team, you have an easier time of creating something that’s going to work for this team that’s going to use your product. So obviously, it takes time and it’s hard, especially when you’re a large organization and you have a specific task you need to work on, but if you’re able to take 10% of your time to kind of learn about what goes on in these other specializations, it will make your own specialization stronger.


[00:08:41] BH: And I’m just curious, what are some of the most important specifics with regards to design for non-designers?


[00:08:49] TO: As a designer, a user experience is very important. So a lot of people talk about user experience first. But when you are not a designer and you’re looking into design, you’re thinking about the visual stuff. Both of these things go hand in hand, but it’s very important to know how folks are going to be using the “what you are building”, the experience they have with going through the product that you’re working on or a specific page or feature that you’re working on. But when people are saying, “I need to become a better designer,” they really are looking at how do I make something look better first. So usually it’s like, “Look better first,” and then they kind of understand the user experience afterwards. And main thing, I wrote a book on this. It’s called Hello Web Design. So kind of what my article is about as well. The main thing, if you want to talk visual design, is to reduce clutter. There’s a bunch of visual design principles when you talk about things like a grid and the colors and typography, and it can kind of distill each and one of these like best practices down to just reducing clutter. So I usually tell folks who are not designers that are in a different area. And they’re like, “How do I make this better?” It’s like, “Well, how can you utilize these design principles just to reduce the clutter on the page and create a really clean design?” Professional designers can create something that can be “cluttery” but still make it work. But if you’re not a professional designer, don’t worry about it. Just go for the cleanest design possible and it’s going to take you about 80% of the way that you need to go. And that’s like adding whitespace, reducing number of fonts you use, reducing the number of colors you’re using. All these things kind of reduce the clutter on the page and can make someone a better designer very quickly. Just get those visual designs looking a lot better and then you can start layering in those user experience principles.


[00:10:32] BH: So you say reduce the number of fonts you’re using. I’m just sort of curious about that one specific element because a developer might think if they want to do design correctly, they should really find out all the different fonts in the right places.


[00:10:46] TO: Yeah. You go onto Google Fonts and the first thing you see are these swooshy things that have all sorts of little widgets and everything, like these really fancy looking fonts. And you’re like, “Ooh!” I mean, that was me becoming my first designer. I started grabbing all these fancy looking fonts and be like, “Oh, I am using a professional non-system font or a non-web font,” Verdana, Times New Roman, all these other ones. So you go onto Google Fonts or onto Adobe Fonts and you see all these amazing fonts you can use. And it’s like, “I’m just going to start layering these things into my design and create something that is ‘more designed’.” For the user who is looking at a visual design, the more kind of visual chaos there is. If you don’t have like a big background design, you don’t have the skills to kind of know how to counteract the visual chaos that could happen with a lot of different fonts, then if you’re a newbie working with a bunch of different fonts, that’s where that reducing clutter comes into play. I always want to repeat, because again, it’s like you already said earlier, I don’t want to speak in generalities. Everything that I say here, there’s always going to be an example about why a beginner designer working at this font can make it work. And I’m not speaking about something like individual, but overall, like just avoiding those fonts, resist that urge to go on to Google Fonts and installing all those fonts, A, will reduce the time to load whatever you’re designing, B, just starting off with something just like one and generally something about it is just like playing text. It’s like a better, best practice moving forward. And this is the advice specifically for folks who are layering on those design skills, but their main focus is something else. So whatever we can do to get that shortcut, to get you to that point of being like, “What are the little shortcuts we can do to make a good enough design so then you could go back to your main competency?”


[00:12:41] KT: Well, I love that advice. Like as someone whose main role is not designer, I have a little bit of training in the visual arts or whatever, but I love that those examples that you’ve given, it may seem daunting, someone who’s unfamiliar with designer, doesn’t have that background, like the idea of, “What is good design?” That's intimidating, it’s kind of a fuzzy concept, but that advice you just gave, I loved it. It’s so perfect. It’s all these very concrete, actionable pieces of advice.


[00:13:08] TO: Yeah. It’s like for all these things, when you, again, have a core competency and you’re trying to learn something new. For design, it’s like, “What are those shortcuts?” And it also works for other things. Like, “What are the little things to know about marketing?” Like the top things you should know about, like copywriting. What are the tricks we can do for copywriting to lead to better conversion? You don’t need to know the whole breadth of the area. You need to know what the little things that your brain has space for. So thankfully design-wise, I feel like clutter is like the number one to help folks get a handle in terms of how visual design works.


[00:13:45] BH: And when it comes to working cross departmentally, a lot of the times this might ultimately help as just putting yourself in the mindset of what the designer is ultimately trying to do. So if ultimately you’re not in an organization where you can directly use those design skills, although I’m sure that they can be used no matter what the context is, at least you’re going to know that the designer is probably seeking to reduce clutter if they know what they’re doing.


[00:14:12] TO: Yeah. Well, there’s always like a little bit of bleed through or whatever you’re working on. Even if you are an engineer and your goal is just to, I don’t know, create for or what are you trying to build underneath that’s running the form, that’s going to be on the front end, and then it starts to bleeding into design because that’s like, “What form fields are there?” And then it leads into user experience, how is somebody maybe using those form fields, maybe don’t want all those form fields? In larger departments, there should be someone who’s kind of owning that experience at the front end, but still useful for you, you the engineer to kind of have that kind of understanding of what’s going to be happening on these other departments because it’s going to ease that communication, ease that process of working with the other folks that might have a different specialization than you.


[00:15:01] KT: Yeah, absolutely. And one thing, I think you’ve mentioned this in some of your writing. I really liked, “So yeah, maybe you’re not designing pages. But as an engineer, maybe you have to prototype something and you’re not starting from mocks.” You’re going to have a more successful pitch when you’re pitching that prototype if it’s a little cleaner, if you follow some of those kinds of simple rules, or even just putting like a slide deck together.


[00:15:24] TO: Yes. Everyone has to do slide decks.


[00:15:26] KT: Yes. It’s the universal. Exactly.


[00:15:27] TO: And the templates that are given by default, I think they’re starting to get a little better and they’re largely awful. And then once you start moving off of those templates, because you have to do extra information, just having some amount of confidence in your visual design skills and just getting to that 20% that gets you 80% there and their presentations are better, your confidence is higher, there’s effects all the way down.


[00:15:50] KT: Yeah. And if you ever need an excuse, like if you’re trying to build that empathy or build that connection with designers, I mean, I don’t know if that’s an opportunity to be like, “Hey, I’m putting a deck together. Can I take five minutes of your time for a couple pointers on cleaning up?”


[00:16:03] TO: Yes. Absolutely. Yeah. That’s a great way to collaborate with your fellow coworker and just learn something new.




[00:16:28] BH: Can we dig into somewhat more nuanced or almost less tangible components of collaboration, especially that developers can understand when they’re working across other departments and just outside their teams? Kate I’m curious what you consider to be kind of the top line guidance beyond some of the hard skills. I think we just kind of got into it that, legitimate hard skill that can kind of help you work across departments in design. But I have to think there’s a lot more to it. Can we start digging into some of that?


[00:17:05] KT: I mean, thinking more stuff that’s more generic or stuff that could apply to and really collaborating I guess any department in general, we sort of touched on it already, but finding those opportunities to kind of build empathy, whatever that might be, and building an understanding of what their work looks like, what their struggles are, what problems they’re trying to solve. Finding those opportunities, whether it’s part of the project that you’re actively collaborating on together or even outside of that I think are really key. That’s some of the stuff. And I always try to keep an eye out for it’s been exceptionally helpful. One thing that happens a lot at work currently is we have a really active kind of customer research team and that I volunteer for those sessions if I have the time. I signed up for them. It’s phenomenal. Often it’s going to be. Customer researcher, maybe a UX researcher, maybe a product person, but it's a phenomenal opportunity to kind of learn more about whatever problem we’re digging into at the time. Whether it’s improving those signup flows or seeing how people interact with, I guess, in my case, I’m usually kind of shadowing things related to pull requests, some on the pull request team. So always learning more about how people interact with that product. But yeah, it’s great. And so those are things that are available. Hopefully, at a lot of companies, those opportunities exist. Yeah. Any chance you can get an opportunity to better understand what these folks in other departments do, how they do it, what they’re thinking about, just trying to shadow them, work with them. Yeah. Those are good things to look out for.


[00:18:41] TO: I like that you call it empathy because it’s like empathy for the other department. It’s also empathy for the folks who are going to be using your product. You know?


[00:18:48] KT: Exactly.


[00:18:48] TO: When you’re jumping into those kinds of opportunities. And by having an understanding about how folks are using the thing that you’re building, I think it does build that camaraderie with you and those other departments. Because I remember reading something where I was like, “How do you make new friends?” And this is a long story, but one of the notes I thought it was really funny about how to make new friends was to have a common enemy. And so when you connect with your fellow coworkers about your common enemy, in a nice way, but your kind of enemy, the person you’re working together, not really against, but it’s like, “What are you trying to serve? Is that customer or that person using a product or that developer is using your open source project?” It does create that kind of camaraderie between departments. This is also going to increase the amount of communication, the amount of empathy you have with your coworkers.


[00:19:37] KT: Yeah. A hundred percent. Yeah, it’s building that sense that you are a team. You have a common goal. You’re all trying to solve hopefully a similar problem, but you’re coming at it from a bunch of different ways. Like I tried to solve that problem with code, I guess, most of the time, other people are solving it from totally different ways. But yeah. At the end of the day, that’s what you share.


[00:19:59] TO: Maybe not different ways, but in collaborative ways ideally. Is everyone’s bringing their skill sets in? The engineers’ code skills, they’re there to kind of beef out that side of the product and then everyone else layering on top of what’s going on and underneath will lead to a better product in the end. I have a lot of empathy also for folks who are really deep in it because it’s easy to forget that, especially when you don’t have those opportunities to talk, A, with your colleagues, maybe you just really focus on your certain department, which does happen. And it’s totally fine. I love the fact that you said you do those customer interviews because I think that does make for a better engineer overall because you get to see what’s going on, on the other side of the screen perhaps.


[00:20:40] KT: Yeah, of course. Well, and it’s tricky too, because like you said, it’s easy depending on what deadlines you’re up against or what size of your team, all those things. It’s easy to kind of go heads down.


[00:20:51] TO: What is your product manager saying to you and what are they doing? Oftentimes, as an engineer, you can’t just talk to the other departments because you have your own department head. Whatever your access might be limited by your manager. So there’s also difficulties there.


[00:21:04] KT: Well, and that’s an interesting thing because we had touched earlier too, like talking about companies of different sizes. And at a startup, the first couple of roles that I had, it was funny. And I don’t think this is an ideal form of communication, but it was the kind of place that was small enough where if I’m working on some integration for our marketing software, I would have folks in marketing, they would walk over to my desk with the rest of the engineers, they tapped me on the shoulder and ask me about it, which not ideal. Yeah, we can talk about it. If you want to have those conversations, there’s definitely better ways to go about it. If you tap an engineer on the shoulder, they’re probably going to jump out of their chair. But yeah, so it’s funny, but when you’re at that small of a stage, maybe you are talking to folks in other departments directly. But you’re right, in larger companies, you’re probably going through an intermediary. I’m talking to my manager and they’ll connect me with so on and so forth. There’s a whole chain of command to go through.


[00:21:59] TO: And there’s good managers. There’s bad managers. There’s all sorts of access levels at different companies that does make this process difficult.


[00:22:06] KT: Yeah. People who were better at facilitating those kinds of connections.


[00:22:09] TO: Yeah. Probably the worst job I ever had was feeling like I was stuck in my own department. It was a 12-person company. I should not have been stuck in my department. And knowing that there are things that I could do for these other departments that could help them out using the skills I had, but they were just like, “No, we hired you for this one solo small thing, and you are going to be working on just that thing.” I’m like, “Let me just talk to you.” And they’re like, “No.”


[00:22:31] KT: Yeah.


[00:22:32] TO: It was very hard for me to feel just like so stuck. The idea that this company was just like, “No, department communication whatsoever.” That was not fun.


[00:22:43] KT: Yeah. No, I hear you. And I think that’s kind of the end of maybe the underlying theme of why are we talking about this. Things are better. When those communication channels are healthy and better and you’re not siloed, you have the information you need. If you don’t, you know who to talk to, and it’s not hard to connect with that person, you’re just going to end up with a better result, better products, happier teams, all the things. That’s what makes talking about this stuff and figuring it out. That’s why we’re doing it.


[00:23:13] BH: What are some of the incentives that can create this kind of friction? Nobody goes out to purposefully make some of this stuff hard, but everyone has their own incentives at work. Can we unpack that?


[00:23:28] TO: It’s been interesting in the last few years with COVID, with everybody moving on to remote work and I think it’s been exposing how hard it is to have this communication between departments when you don’t have a water cooler to stand around. When you can create ways to communicate in a non-work fashion, if you can set up places, retreats or happy hours, remote happy hours or whatnot to kind of great places where people can have conversations and form a connection with folks in other departments first that is not related to their day-to-day job, it will lead to better communication down the line by having those things set in place. Because otherwise, if you think about the other way around, which could work, but you’re working on your project and you get pinged by someone who have never met before and never talked to before, they want to talk to you about what you’re working on, I certainly would react more defensively in that situation if I don’t have some context around that person and what they’re working on. And so in terms of incentives, the first thing I think of is, especially in a remote work culture is, “What can you do to create ties between the folks who are working at your company and especially not necessarily directly related to a department is going to make those communications down the road easier?”


[00:24:45] KT: You’re absolutely right. I'm remembering those days when we were in that office, in that physical space, and it’s that awkward human thing, right? I can speak for myself at least. I would certainly feel awkward just walking up to, like you said, in a different department who I’ve never interacted before. Something in the past that I maybe would have been hesitant to do, unless I had some work-related reason. Yeah. That’s where you want folks, and it doesn’t have to be managers. It could be anybody. But yeah, just making that more of a norm. One of the things that I really liked where I am now, it’s a fully remote company. So to kind of recreate some of those spontaneous conversations or meetings, we have little bots that will randomly, hopefully this sounds familiar or the folks who’ve seen this before, but yet it’s like just a little chat bot and it connects to people and says, “Hey, take 15 minutes, do a virtual coffee.” Those conversations are amazing. I do probably one of those a week and it’s a great way to meet folks who I wouldn’t otherwise interact with.


[00:25:51] TO: I find a lot of managers struggle with those things because they’re like, “It’s taking away time from what you’re working on.” It’s like, “Are you being productive right now?” But that’s like the easiest way to just kind of allow those kinds of communication channels when you’re working on a fully remote team because otherwise we were all stuck in our houses feeling kind of lonely, just grinding away or working on, probably not feeling very optimistic about things when you’re kind of stuck. Now it’s going back to the word bubble. It hits your own personal bubble and those kinds of communication channels, A, can help within department, but also it can be valuable across departments.


[00:26:23] KT: Yeah. And I think you touched on another. So yeah, there’s like the human awkwardness thing where it’s like, “Okay, I’m not just going to randomly talk to somebody,” but also in terms of incentives, there is, there’s that whole productivity thing. Those kinds of conversations are framed as unproductive or unhelpful. Yeah. You’re less likely to do them, but at the end of the day, best-case scenario, you have some sort of amazing spontaneous ideas session in connecting with that person. But even if you don’t, hopefully it’s like the mental health thing, right? You’ve connected with other humans. It makes you feel more connected. It makes you feel better. And then the rest of your day, you’re more energized and you’ll be more productive. Personally, I enjoy working somewhere where that’s what they’re incentivizing, right? Maybe it’s not directly related to my immediate task that I’m working on, but it’s not always the time. It’s still very valuable and it helps me be productive and also be happy about what I'm doing.


[00:27:20] TO: This all has to be like a leadership-led initiative from the top level of the company down to the managers to kind of allow for these kinds of opportunities and kind of expect that there’s going to be time out of your day to set up a session call and probably individuals being like, “Oh, I don’t want to do another 15-minute whatever Zoom call. I’m on Zoom all day. I don’t want to do anything like that.” But having the ability to look long-term and what are the benefits that’s going to happen with this product long-term by having that individual, that one-on-one between these two departments can lead to maybe an initiative where that one department is doing customer interviews and they want to bring in the other department just to kind of watch and learn from that, which is going to lead to maybe the other department, maybe that’s the engineering department, creating a product or creating things underneath the back end that it’s going to work better with what they’re planning to do on the front end because everyone has a better idea of the customer experience, which is then going to lead towards those probably better profit, better experience on the front end, which means more customers when you’re converting or something like that. And the top level people are always looking at what’s the amount of revenue coming in. So it can be aligned directly from, it’s kind of hard to visualize, but align directly from that one on one between two coworkers can lead to something that is going to bring the company where revenue eventually, but it’s hard to visualize that. It’s easy to visualize. I can get more productivity out of my employee by not having these initiatives. And so something that’s very short-term and visual versus something that’s kind of nebulous and long term, then that goes into, like, whether the leadership has the ability to kind of see those kinds of eventual benefits.


[00:29:03] BH: What about that mistake of thinking that one has to sort of work in a hyper-focused sort of context to be productive or to be doing their job? And you sort of mentioned the mistakes that a manager or a leader can do about how people ultimately are productive. Just like, “Don’t spend your time on superfluous connections that don’t actually directly affect the work.” But as an individual, someone might have that same inclination to avoid taking part in those sorts of programs for their own reasons or maybe it’s out of their own enjoyment. It’s just not part of something they like doing, but sometimes it’s about how is this helping me hit my goals to ship these tickets, to fix these bugs, to finish these features. How do folks miss the point on some of that stuff? Or what’s the fallacy there?


[00:30:02] KT: I’ve certainly been on projects where that was absolutely the thing. We kind of took that waterfall sort of development approach, where everything is planned out. We know exactly what we’re going to build. They hand off those plans to developers. We’re heads down. We crank it out and then we hand off the end result. Yeah. And then the stakeholders are like, “What is this?” The thing that they had asked for and the things that we had so meticulously, their product and design, so meticulously researched and mapped out and designed and then the engineers had gotten that and shipped these pixel perfect products that it matched exactly what that thing was that we thought they wanted and that they told us they wanted six months ago. But at no point where we checking in. We weren’t having those regular demos. We weren’t kind of sharing the progress with folks who would ultimately be using this thing that we were building. And so yeah, when it came time to just kind of do the big reveal and just be like, “Tada1 Here it is. Here’s this amazing thing you asked for.” They’re like, “Oh, thanks.” Everyone was trying to be polite. It was like, “Okay, great. Yeah. I’m so glad this launched.” And when we checked in with them, like a month later, they weren’t using it. They were using whatever tool they had been using before. Right? That supposedly we had built this amazing alternative tool, but it wasn’t amazing because we didn’t check in with them. We didn’t collaborate. We were too siloed. And so yeah, that I would look at, in terms of waste of time, unproductive. It certainly felt productive. We felt very busy.


[00:31:36] TO: But what a feeling at the end, right?


[00:31:37] KT: Exactly. Yeah.


[00:31:39] TO: You're like, “That sucks.”


[00:31:41] KT: Exactly. Nobody felt good. You felt like this wasn’t a good use of time, energy, resources. None of it. It felt horrible. So yeah. Then we dropped the waterfall approach.


[00:31:50] TO: Yeah. I’m visualizing those memes where it’s like, “What the customer wants?” And it’s like a swaying tree. And that’s like, “How engineering visualize it? How marketing pitches it? How sale sells it?” It’s like every single one of them is a little bit different. And that’s like the classic communication.


[00:32:07] KT: Yeah. And it’s funny. It’s a common pattern that folks can fall into, I think it’s an approach certainly, has its advocates, but I’ve seen better results checking in.


[00:32:19] TO: When you can just be siloed and just work on a product and everyone understands each other within your small department, you’re not talking to other people, you’re also avoiding the fact that someone might come in and be like, “No, not that.” And it’s tempting. I say this as someone who’s done a lot of solo development, and as I don’t want to show what I’m working on when it’s halfway through because I want to get to completely perfect because I feel like I don’t want feedback in the middle part because I’m still building it out. There are still things to be done and I don’t want to get off track with wrong suggestions or someone not understanding things. It’s almost always like, I don’t know, it’s a very human thing. So it’s always something I regret because I’m like, “Oh, right!” That is why you check in with other people because you get like a tunnel vision when you’re working on this project and you don’t see what other people are seeing or what they’re not seeing. You don’t see the things that you might be missing because of this tunnel vision. It’s funny saying this when I’m on here. I am absolutely an introvert. I can pull out the extrovert in me to talk about these kinds of things, but I work as an introvert. I don’t want to talk to other people. It’s why I worked solo for so long. I looked back at that time and be like, “I just didn’t want feedback from anyone. I want to build what I want to build.” Looking back on it, that’s also why my startup didn’t take off. Eventually, I had to shut it down because I wasn’t getting feedback or talking to other people. So anyways, that’s my own little anecdote. It’s always something that I do it often enough that I’m like, “Oh, yeah, that.” This is why communication, feedback, and then slowing the process down just enough that you can talk to other people and get other perspectives. I’m constantly reminded about why that is necessary.


[00:33:52] KT: Yeah, totally. And like an even more recent example. So I was part of the team that just delivered the new file tree feature for pull requests, which when that was pitched, when we were like, “Okay, this is what we’re building, we’re building a file tree,” I mean, that seemed like a rare opportunity where it’s like, “Wow! This is easily the most well-defined part. We know what we’re building.” Right? No ambiguity. I know how to build a file tree. We have tons of examples. You had the project requirements down. That was one of the rare occasions where at the offset, at the beginning, we were like, “Oh, cool. We can totally just go heads down on this.” Let’s crank out a file tree, ship that, and everybody’s going to love it. And even something like that, even something that seemed super well-defined upfront, very clear requirements. It was wild when we staff shift it. We got all kinds of really helpful feedback, stuff that just had not occurred to us that ended up getting incorporated and do the beta launch. And then after that, even more things were incorporated in. So it’s funny. It was a nice reminder. It was a nice reminder that, yeah, no matter how well conceived you think you have this thing, yeah, there’s a lot of really smart folks out there who are going to give you some even better ideas.


[00:35:07] TO: Absolutely.




[00:35:29] BH: As an individual working through a problem where you’re not necessarily seeking explicit, organized feedback, but it’s like feedback meets rubber ducking, how do you put yourself in the mindset to seek out the right type of feedback and then listen for the parts that matter to you and take it for what it is, pick the things that are not useful with a grain of salt and then listening for what truly might be useful? Any tips on that type of process?


[00:36:02] TO: It’s a trainable skill. I’m not the best at it still, but once I kind of looked at it, and not in binary, that someone has a skill, I don’t have a skill, but it’s something that I can practice. The practice of going out and getting feedback and kind of letting the bad feedback wash off of me or the feedback I don’t agree with and not take it personally and practice feeling the effects of the benefits of going out and getting that feedback, every time it becomes a little bit easier. And so when I’m kind of faced with this problem, I don’t look at it as in like, “Oh, I’m still bad at this.” I kind of look at it as, “I still need to practice this.” And here’s an opportunity to practice this skill that’s going to make a better person, a better worker, I guess, moving forward, because I know that I know what the good effects are. I know that it’s hard for me, but I know that I need more practice. And even if it’s like harder than normal, it’s just like someone doing sports and maybe they had a bad day. Maybe I have a bad day and that’s okay. But every time I do it, the next time I have to go through this process and be a little better at it.


[00:37:10] KT: I totally agree. It’s definitely something that takes practice and you can get better at. And that’s one of the things I love, like whenever I’m on these protocols, I love learning from some of our product managers or some of our designers, being able to, yeah, really be able to zero in, like kind of sort the signal from the noise, zero in on the feedback that should be incorporated. And even just thinking like, “This is a great idea, but we’re going to save it for later.” So not only being able to identify what’s important, but what’s important and when. Yeah, it’s just really impressive. And thinking of practice, it’s funny. It’s almost like you’re back in art school again, right? Like going through critiques.


[00:37:51] TO: Got to hate critiques.


[00:37:52] KT: I know. They’re the worst.


[00:37:53] TO: You and I can connect on this. I hated critiques so much. I was so bad at them. I wish I could go back to that experience and redo them now with the experience I’ve had since then. Because I went into those critiques opposed to being like, “This is useless for me. I don’t want to be here.” And it’s funny you bring it out. I didn’t really think about that, but that same skill set that you can get in these areas, this feeling of what I’ve worked on is my baby. I’ve worked hard on it and probably you worked on something, utilizing all the requirements and then someone’s going to come along and be like, “Actually, there’s another requirement and maybe you didn’t know about it in the first place, but there’s another requirement.” And you’re like, “Rah! I didn’t know about this requirement.” You take it personally. It’s like it’s an attack on you. Like, “Why didn’t you just like magically understand this requirement?” And it’s like this skill just to be like calm yourself down, realize that that thing they need to add that the person brought up that should have been in there in the first place, but maybe it wasn’t there, it’s totally fine because now you can take that time and make something better afterwards. The critique of my beautiful logo that I put up, actually it turned out wasn’t beautiful because then I learned some new information and that sucks and I have to redo that time. But in the end, having that extra information, it’s going to make the final product stronger.


[00:39:05] KT: Yeah. Exactly.


[00:39:06] TO: That’s very human to hate that process. I still hate that process. It’s just human.


[00:39:10] KT: Totally. I think about it. I still think about it. Like every time I open a pull request for review and it’s the same thing, right? Like I’m getting feedback on this mental output, this creative output, like the thing that I put together. You got to be brave and it gets easier overtime.


[00:39:27] TO: Focus on the results and just understand that sometimes the process, the journey that you take to get to the result can be messy, lots of wrong turns, and sometimes you have to turn around entirely to go on a different route. But yeah, I think it’s also a good mental practice is when you get to the end of the road, when you get to that final product and you know that you’ve gone through this process and it might’ve been hard, but you’re there now and it’s working and it’s out then you can kind of mentally celebrate the struggle that went into it and then prepare for the next round. It’s like you pat yourself on the head for getting through that process.


[00:40:02] KT: Yeah, totally, which is a good expectation. I’m thinking of anytime we’d done like kind of a cross team project, that’s such a good expectation to kind of set up front. Because you want to get that feedback. You want people to feel empowered to deliver that and not save it as a surprise at the end.


[00:40:18] TO: Right. Yeah. But just by saying to someone else, “I am open to feedback,” is going to help improve that communication process from the outset. Because I can imagine maybe if you didn’t say that explicitly or maybe because you’re remote work, you don’t have that back and forth, maybe you don’t have that connection with that coworker and they’re in their own world going, “Should I say something? Should I? Maybe this is not a good idea. Maybe not.” Or is it like just having that conversation could make the final product? Maybe it’s like, “Oh, yeah, you have this connection with it for someone and you realized that you are missing something, to say in the beginning, the communication lines are open. You can be proactive about helping other departments work with you will also make the whole process easier.


[00:40:59] KT: And kind of like telling people that you’re open to feedback and soliciting it, but then modeling what that might look like.


[00:41:05] TO: Yeah, but also setting guidelines. Don’t tap me on the shoulder while I’m working. If you see me heads down, wired in, I am like in a flow, don’t interrupt the flow, but there are these other times, so-and-so times that you prefer, ways you prefer to be communicated with, like send an email over and I’ll get to it at some point or send me a Slack DM because my do-not-disturb hours are set up. So you don’t have to worry about bugging me at the wrong time. By being explicit about the ways that someone can’t communicate with you, that also makes that whole process easier.


[00:41:36] KT: A hundred percent. Every time I’ve kind of given this talk, like back to the thing I initially wrote, I have a little section about that, where it’s like thinking about communication methods. Yeah, it’s funny because every time I give it, somebody comes up and they’re just like, “Oh, no, I’ve been doing it wrong. I’ve been tapping engineers on the shoulder. Do they hate me?” And it’s like, “No, no, no, no.”


[00:41:59] TO: Again, it’s human. Right? You see someone across the room, you want to go over and say hi. I worked right next to my husband and we do it to each other and we also annoyed… But we know this. But you’re looking at the person or looking down and you’re like, “Hey, what do you think about this?” And they’re like, “Huh? I was in the middle of something.” It was just a human thing. We’re just like, “Hey, I have my headphones on. It’s a sign. Leave me alone right now.”


[00:42:19] KT: Yeah, it’s definitely a great thing, like yeah, I don’t know how to fix that. Same thing happens here.


[00:42:26] TO: It’s human. It happens all the time, but there are ways that you can kind of set up some preferred guidelines, I guess.


[00:42:35] KT: Yeah, totally. And I love being on teams where everybody’s on that same page and we kind of help each other follow those communication norms. They’re set up and then you just keep kind of reinforcing them.


[00:42:46] TO: I mean, that’s how you can work better with your own co-workers is by establishing something as a group, what are some guidelines as a group. And the end result is that you’re going to communicate better as a group. You’re also going to have that camaraderie, like determining those things together. We as a team, this is how we work. I think also just kind of helps that team cohesiveness.


[00:43:06] BH: One final topic, which is specific and can maybe be derived from some of the more general discussion, but let’s talk software tools that maybe you’ve come across that like using them well helps break down team and department barriers in your experience, and also just sort of coming to compromises and making decisions when different people want to use different things. How do you manage that sort of stuff? People have their preferences.


[00:43:41] TO: I work remotely. I mean, in terms of specific tools, everyone’s using Slack. I wish I had something like a niche tool. I would really recommend. But on Slack, for the different departments, there’s sometimes this urge to lock the departments’ channels and those specific topics. So no one but that department can be a part of that channel. And it can be very helpful for folks from other departments, maybe they’re not participating, but if they can see what’s going on in those channels, there are ways to make sure this isn’t distracting to other folks, but just by allowing folks to see the discussion that’s happening in these other departments is kind of like step one to that communication because you can see what they’re talking about. You can kind of be a fly on the wall in the room as they’re probably discussing something. You can learn things from that. So for those folks who want to block those channels because they’re like, “You’re working in this department, it’s your department only and we’re going to hide that,” maybe that applies specific project channels, but by keeping some department communication channels that are more general, keeping those at least visible to other folks in the company so they can kind of be that fly on the wall and see how those things are working on the other side is going to improve that communication. Something that I even struggle with in my current job where we had that siloing and we were just three people. It’s like, “We need to like unsilo these things because they're going to bleed through in a small team.” So small teams I think is especially important. Large teams, it could just help folks kind of have an understanding what’s going on in other parts of the company and help break them out of their own little silo and their own little bubble.


[00:45:15] KT: Yeah. Completely agree. Defaulting to public, defaulting to that transparent communication, it’s so helpful. In the end, you’re at a company where everybody trusts and respects each other. It’s awesome. It’s the best thing ever. And it’s funny too. If those conversations are public, they’re easily searchable. And oftentimes, I will actually look through the company chat first before going to the dots because more likely than not someone will have had it. It’s like, “Why does it work this way?” Or like, “How do I do whatever thing?” It’s in there. Someone’s already had a conversation about it and that’s where I can find it and I can say thanks. I don’t know, it kind of cracks me up, but I’ve started relying on that first, just because currently that’s the default.


[00:46:00] TO: Tells you that it needs to be another tool somehow.


[00:46:02] KT: Yeah.


[00:46:02] TO: We’re not there yet. There’s no good tool right now I think to kind of grab those conversations, but we are moving from largely say 10 years ago where everyone was in person and those conversations of course were recorded. So at least they’re there and we can access them. That’s I guess one of the few benefits to remote work. But in terms of communication to remote work, there’s so much communication barriers, but it does mean that those things are generally recorded and you can reference them afterwards. Well, that’s something that didn’t exist before, which is kind of cool.


[00:46:31] KT: No, it’s great. Having everything, and this definitely applies to remote, but I think it applies even if you’re not, having everything written down and discoverable, it’s the best. It really pays off. The other thing, Ben, when you asked, like the first thing that came to mind in terms of, and this is like a very engineering brand thing, one of the things I learned very early on was it comes back to writing as well. Engineers, we would tend to anything we communicated, we would default to just writing it and mark down. Right? And so we would kind of expect, without asking or without acknowledging, frequently, we would just expect whatever team we were, the marketing team or the sales team or whoever we were working with to also write markdown, which was wild. Don’t do that. That’s what I learned. Please don’t make people do that. I’ve seen resistance to using just some regular…


[00:47:24] TO: Rich tech editor type thing?


[00:47:26] KT: Exactly. Exactly. I’m trying not to like throw brand names out there, whatever, but yeah, just use the one. Use the one that’s easily shared that everybody else uses. Don’t write it in a markdown. You’re asking someone to learn essentially a whole another language, written language just to talk to you. And I think that sounds reasonable.


[00:47:44] TO: I mean, as a communication thing, you don’t realize when you’re used to markdown, your brain is like looking at and understanding what’s going on behind the scenes. And they see like the double hashtag or whatever, I call it double pound, and they’re like, “Oh, yeah, H2, semi like second level headline,” your brain is like a whole other language. Your brain is like, “Cool. I know what that means.” It’s hard to remember that there’s a learned process to understand that language and other people don’t have that immediate, like picking up on that language and they’re saying, “What’s going on?” And just like, “Why is this talking about covered in symbols?”


[00:48:18] KT: Yeah, exactly.


[00:48:18] TO: There are symbols everywhere.


[00:48:19] KT: And I think about, like once you start looking at the links, the links syntax or footnotes syntax, come on, get out of here.


[00:48:26] TO: They’re like, “This URL is twice and there’s like symbols around it and whatnot.” As someone who loves markdown, totally agree though.


[00:48:35] KT: Same. Yeah. That’s the thing. And so that’s something very early on. Give that a try. Try to try to meet folks. Find that shared piece of technology. Maybe you don’t get to use your favorite tool or use your favorite, whatever, but that shouldn’t be the goal. You should use the thing that works for both of you.


[00:48:49] TO: The overarching idea is, “How can you communicate? And is there a way that you communicate that doesn’t necessarily translate to this other department?” And a very good example could be marked down and that’s something to kind of understand and learn and can help you communicate better once you understand that that’s something that you share.


[00:49:07] BH: Thank you both so much for joining us today.


[00:49:10] KT: Awesome. Yeah. Thank you so much.


[00:49:10] TO: Yeah. Happy to be here.


[00:49:20] BH: Thank you for listening to DevDiscuss. This show is produced by Gabe Segura. Our senior producer is Levi Sharpe. Editorial oversight by Jess Lee, Peter Frank, and Saron Yitbarek. Our theme song is by Slow Biz. If you have any questions or comments, email [email protected] and make sure to join our DevDiscuss Twitter chats on Tuesdays at 9:00 PM Eastern Time. Or if you want to start your own discussion, write a post on DEV using the tag “discuss”. Please rate and subscribe to this show on Apple Podcasts.