Women in Tech

Mentoring as an engineering manager

In this episode, I talk to Jess Rose, who specializes in community building, outreach, and developing better processes for talent in technology.

We talk about:

  • her process of mentoring other developers – from junior to senior – via online 1 on 1
  • how managers can and cannot advocate for their team
  • how mobile devices are omnipresent as development devices, yet they come with a lot of challenges,
  • and code reviews and the importance of a shared language.
Jess Rose

Today’s episode is sponsored by Mergify, the faster and safer way to merge your code.  

Subscribe on iTunes, Spotify, Google, Deezer, or via RSS.

Transcript: 

[If you want, you can help make the transcript better, and improve the podcast’s accessibility via Github. I’m happy to lend a hand to help you get started with pull requests, and open source work.]

[00:00:00] Dr. McKayla Hello, and welcome to the Software Engineering Unlocked podcast. I’m your host, Dr. McKayla and today I have the pleasure to talk to Jess Rose. Jess is a technology professional and keynote speaker specializing in community building outreach and developing better processes for talented technology. She is passionate about fostering more equal access to technical education, and digital spaces. But before I start, let me tell you about an amazing startup that is sponsoring today’s episode Mergify. You know, I’m all about code reviews and pull requests. Having your teammates review your code can be super beneficial, but it also can create a bottleneck and slow down your software development. With Mergify, your team can be way more productive with GitHub. Mergify automates all about merging pull requests, you can specify the merge conditions, and Mergify will take care of the rest. Do you want a specific order for merging the pull requests? Should one PR be prioritized? Or do you need a copy of the PR and another branch for bug fixing? No problem. Mergify can take care of all those situations. By saving time, you and your team can focus on projects that matter. Mergify integrates completely with GitHub and your CI pipeline. They have a startup program that could give your company a 12-month credit up to $21,000 of value. Start saving time, visit Mergify.com to sign up for a demo and get started or just click the link in the show notes. I’m super, super thrilled to have Jess here with me. Jess, welcome to the show.

[00:01:38] Jess Rose Oh, gosh. And I’m absolutely delighted to be here when you said hey, do you want to come and talk about teaching and learning? Oh, I’m just going to be insufferable. Thank you so much.

[00:01:48] Dr. McKayla I’m really excited because I’m following you on Twitter. And I see that you’re creating spaces for people to learn to get better to grow. Right. So there are a couple of things that I want to touch base on today with you. One is the 1-1s that you’re offering. So maybe, maybe let’s get started with that. Because I see you from time to time you say, you know, I have some time available, why not hop over on a call, and I can help you with some career advice? How’s it going? What do you do with people? What kind of people are picking up on that?

[00:02:27] Jess Rose So I’ve been doing this for about, I looked the other day because I do, I do keep records and privacy-preserving records just like, oh, what kinds of things am I talking to people about? And I’ve been doing this for about eight years now. So just broke 1700 folks I’ve talked to over the years.

[00:02:40] Dr. McKayla Wow.

[00:02:40] Jess Rose And you would think oh, it’s going to be mostly juniors or mostly people trying to break into tech. But just the absolute vastness of experience is so dazzling and exciting and strange to me. I don’t see myself as especially well suited to give great advice. But on these calls, people are almost never asking for actual advice. So a lot, most of it’s just, I’d like to be heard and I’d like someone to confirm that my experience is unusual or isn’t unusual. Or getting sort of a level check for a different area saying, Hey, I’m based in this region, and I’m looking for work in your region. What’s that like? What’s the experience like? What’s the process like? I actually documented the whole process out because I want, I definitely want other people to be doing this if you feel like it. No pressure. And it’s on my GitHub. So GitHub.com/JessicaRose. And it should be right on there as 1-1s.

[00:03:37] Dr. McKayla Yeah, I saw that. I saw that on your Twitter feed. So it tells us how to do those 1-1s and how to, what questions to ask, and so on?

[00:03:46] Jess Rose Yeah. And mostly just about the tooling. So how to get it scheduled, how to get that sorted? And then because I’m a weirdo, how to get the records of who chatted to you deleted if you want to, like, yeah, I wouldn’t keep notes on somebody who doesn’t want me to keep notes.

[00:04:00] Dr. McKayla Yeah. And I think it’s good for privacy as well, right?. If people I don’t know which topics, they are coming to you, but I mean, some of them might be private, and you know, especially if you’re having maybe, like, I think if you need advice, you’re very often not such a good place, right? Probably more than being in a great place where you think, well, everything figured out, you know, things are going smooth than you’re seldomly reaching out to other people. It would be like I’m bragging now to you. You’re more probably reaching out if you have some problems with your team maybe or getting a job or something like this. Is that what people talk to you about in the sessions?

[00:04:41] Jess Rose So anything from, Hey, am I getting paid right? To, Oh, I’m getting screamed at a lot at work. Is this normal? So a lot of them are sort of, oh, gosh, but a lot of times folks just want to explore what’s going on next. I’ve managed people a lot in my career. And one of the things that I always, I always have a difficult time with, and I hope other managers do, too, is how do you deal with the conflict? And there’s always going to be conflict between what’s best to the individual person you’re managing, and what’s best for the company because those are those, And one of the big things I push when I do manage people is, hey, do you have someone external to the company to give you good advice when I can’t? Or I shouldn’t give you the advice that’s best for you?

[00:05:31] Dr. McKayla Yeah, yeah, it’s a conflict, right? Because obviously, you don’t want to lose that person. But you see that they’re outgrowing, you know, maybe the position?

[00:05:42] Jess Rose Oh, I really just want to chase this up a minute. I’m always like, you don’t want to lose somebody, like, you don’t want somebody to move on for your team because they were unhappy or mistreated. This is definitely from me being a teacher for too long. I’m always pretty excited when somebody graduates up out of a team I run. Like, of course, you want to make sure that people have space to grow, of course, you want to be actively making sure there’s career progression and more things to learn. But and especially in a job market, like right now, sometimes people like oh, cool, I could make a bigger salary jump bracket, they could make your title jump by leaving. And I’m always pretty chill with that.

[00:06:24] Dr. McKayla Yeah, yeah. Me too. And my husband is also managing a bunch of people. And but I see tension there, right? So I think he’s always really behind the people. But then upper management would be, yeah, but you know.

[00:06:38] Jess Rose The business case for retention.

[00:06:40] Dr. McKayla Exactly. Right. And the same for, for example, giving your raise, right. And I think, especially maybe the managers, you know, that are really like first line, they are more for the people because they have like some personal relationship, and then one level up, it’s already like, yeah, but you know, we don’t have the budget or we don’t want or we believe we can still keep that person, you know, for this for this cheaper?

[00:06:38] Jess Rose Oh, well, you know, let’s give it another quarter or two and wait and see.

[00:07:08] Dr. McKayla Yeah, exactly, right?

[00:07:10] Jess Rose Baffling.

[00:07:11] Dr. McKayla how do you do that as a manager? How do you speak up for your, for your people, or for your team? And h ow do you deal with that conflict as well?

[00:07:22] Jess Rose So I think that’s a really challenging one because I think that the conflict there is still the same. What do you do as an individual manager when the y eah, when your contractual, your fiduciary duties to your company, run counter to your individual ethical responsibilities to the people you manage? And or what happens when there’s a conflict between the needs of an individual and the needs of a team? And it’s not a good answer. And it’s not a reassuring answer. But it depends. If somebody is facing treatment that feels unfair, or targeted, or they’re in a position that I, generally, if somebody is in a position, I’m not okay, with being much more lovingly strident around, hey, this is a topic I would really bring to your external mentor A well, and then setting really clear limits internally about what, even as a manager, you are and aren’t willing to do. So somebody saying, Oh, you get the idea that, Oh, maybe we want to manage so and so out, go ahead and write them up for stuff that the rest of the team routinely does. You still have consent as a manager. So you could say, like, yeah, no, I won’t work in a space that involves maybe this kind of behavior.

[00:08:45] Dr. McKayla Yeah, yeah, I think this is really important that we are standing up for our own ethics and for our own beliefs and value and, you know, also behind our, you know, our people that we, you know, I think we have a responsibility as well for and yeah, so I yeah, I can totally see that.

[00:09:05] Jess Rose It’s easy to say in this kind of job market in the West as well. I think, a re you based perhaps in Europe as well?

[00:09:12] Dr. McKayla Yes. Yeah.

[00:09:13] Jess Rose Because, like, these days for many European job markets in tech, finding a new job feels to many people who are established for juniors or people getting your first job, It is hard. But for folks who’ve been in for a little while, and folks in different in high demand areas, getting a new job as a junior as a middleweight, or a senior, is not as difficult as it could be these days. Whereas if you’re having to engage in management behavior that you’re just not comfortable with, yeah, sometimes changing jobs is easier than making peace with uneasy ethical decisions. Yeah, sometimes that’s not true for everybody. And it’s a very, very privileged take for those of us who have a little bit of wiggle room.

[00:09:58] Dr. McKayla Yeah, I think so. And it really depends on where are you located? And what is your personal situation, right? Do you have dependents? Do you have like family or people that you have to take care of? And so on, which I think makes it much harder to say, you know, I’m going to not do that. But I think there, you know, there are boundaries, it’s, it’s one thing is playing along, and just, you know, or letting the other person also, you know, know, in the space that you have, right? You’re also like, as a manager, you also, you can’t just go and, you know, give advice directly conflicting with the interests of your upper management because that, you know, is a problem, but you can, you know, talk a little bit about, as you said, maybe asking you an external person, or also I think very well, you can say I’m disagreeing with this decision, right? And I advocated for you, unfortunately, you know, these were my boundaries here, for example, and let them know, I think that’s, that’s perfectly fine. Yeah. And I think that the problem is that if more of those things come together, people start thinking about leaving, right?

[00:11:06] Jess Rose And that’s not always a bad thing. As a manager, if you’re not able to offer someone, a place that is safe, and productive, and non-traumatic to work, yeah, it’s okay, that your people move on, and actually kind of preferable?

[00:11:22] Dr. McKayla Yeah, yeah, I think so, too. So another topic that I wanted to talk with you about, and it’s a little bit related to management, but it’s more related to teaching. So I don’t think you have to be a manager to teach, right? You can be, you can be, you know, Junior Dev, Mid Dev, senior Dev, right, so we can all learn from each other. But I really see you as a teaching, you know, expert here. Yeah. Because you’re, you’re bringing topics around programming, but also, you know, advice for hiring or you know, how to get hired. And to so many people, right, you’re, you’re also making these really mass, mass online learning events, right, occur online boot camps. So how is that going? Why did you start that and is that only for really junior people?

[00:12:12] Jess Rose So the first thing I want to do is like, I would absolutely love if there was an excuse for me, Oh, yes, I’ll just take all the credit. But the free online boot camps that I’ve started are absolutely not just me. So they started as 12-week boot camps, and they’ve been collapsed into a reasonably intense but still part-time, six-week boot camp. And this is built off of the freeCodeCamp curriculum. So they’re a registered nonprofit. They’re amazing. We could not do this without them and without their permission. But also the good people, I’m pointing behind me like they’re back there. The good people Class Central built a whole platform that lets us teach on so like, just really, and Ramon is my, my co-teacher. And he’s he’s just, it’s almost disgusting how lovely he is. Like, the learners love him and deservedly so.

[00:13:03] Dr. McKayla Cool. Yeah. So what do you teach there? Is it like really the 101 of programming? Or is it more advanced concepts? Who is your target audience here?

[00:13:14] Jess Rose So this last cohort, which just ended about two weeks ago, I should get back to work on those. We had 15,000 unique learners across two tracks learning either web development, which is HTML, CSS, accessibility, really, really intro level of like first steps of programming, or across JavaScript. And again, that sort of first steps with JavaScript, getting started. So really sort of introductory level. But we added some additional forums for peer support. We’ve got a very noisy Discord. And then some live stream lessons and question-answer to get people unstuck. We’ve had such a, so I would have expected oh, these will be beginners. We have back-end devs who wanted to try out web development. We’ve got folks who don’t want to go into tech, but they do want to build a website for their business. And the thing I was, I used to be a teacher and I used to be a linguist. And very selfishly, the thing I was, one of the things I was most excited about was the absolute range of the learners. We’ve got folks across every regularly inhabited continent. And folks joining us in this massive exciting range of first languages. I was just so, so people who are learning from their phones, people who are learning from the library computers, and I just really really loved this loud, chaotic, and so lovely and so supportive group of learners all helping each other out.

[00:14:49] Dr. McKayla Yeah, that’s, that’s really exciting. So I actually was thinking a little bit about learning on devices that are not high-end, right. And when I, when I started university, I couldn’t afford a really high-end computer not even a normal computer, right? So I was on this, I got, I got one of those really cheap computers from somebody that you know, gave it to me for free. And it was a nightmare. It was a nightmare to work on that. And nowadays, it’s obviously not the case anymore. And I’m really happy about that. But I was wondering what about, you know, people that don’t want to work on the phone or work to, you know, on a tablet, and I’m pregnant right now.

[00:15:32] Jess Rose Oh, congratulations. How exciting, how scary.

[00:15:36] Dr. McKayla Yeah. But it’s also a really cool experience because I’m thinking, like, this is my third child. So I know a little bit.

[00:15:45] Jess Rose Oh, you’re just fine. You’re like, duh, this happens.

[00:15:46] Dr. McKayla I know what’s going to happen, that I can sit here and you know, work on my comfortable devices. And so I tried a little bit to work on my phone and work on the tablet and so on, I still think it’s really difficult. What tools do your learners have?

[00:16:03] Jess Rose Did somebody, somebody did one of my friends talk to you about this? I’m deeply suspicious. So I’m going to try really carefully not to say too much. I’m working on a little side project around this problem. Because this is a problem I’ve been thinking about a lot. So right now, and if our dear listeners aren’t your viewers are, oh, gosh, what’s the noun? Our beloved audience, your beloved audience has a tool or has something in the space that I haven’t seen yet, please come and yell at me. But right now, I’m not seeing really good tooling. I’m not seeing a good way to write to the web from mobile devices.

[00:16:46] Dr. McKayla Yeah, it’s not there.

[00:16:47] Jess Rose And this is an ethical problem for me. Because right now we hear people talking about the next billion users, I love this. But in a lot of cases, we’re seeing people who are accessing the web for the first time, and I love it, and I live for it. But they’re accessing the web on a lot of constraints. So they’re usually on phones, they’re usually mobile-only is what we’ll call those kinds of learners. They may be accessing it in their third or fourth language, because you’re going to see global web primarily in English and French and Spanish. And they’re often constrained to really, really challenging limits on their, like their actual access to broadband or to mobile signal. And that’s something I’ve been thinking about a lot on the device level for this problem. If I went, I’m going to date myself terribly. But I got access to the internet, when I was maybe 13, or 14. And the device I use to access the web to read the web, I could also write to the web. And we’re effectively giving people this right only access to the web through smartphones. And that just, that doesn’t seem like enough to me. So there’s nothing great yet. And I don’t think I’ve necessarily cracked it myself. But in the next couple of months, I would like to, I’ve got a little thing I’d like to launch to see whether or not that might be a good tool.

[00:18:10] Dr. McKayla Yeah. Cool. I would be super interested in that. And I also think like, nowadays, I’m actually, I should actually be the whole day on bed rest. But two weeks ago…

[00:18:20] Jess Rose What are you doing? You should be doing this lounging.

[00:18:23] Dr. McKayla Yeah, I should. Right, yeah. But so now I’m allowed to be up a couple of hours per day, which is, which is great, but because I’m on this bed rest, right, and I only can lie down, I’m not allowed to sit actually, I experienced all these accessibility problems that, you know, couple of, you know, disabled folks also are experiencing and I’m like, right now, I really understand how difficult it is if you can’t, you know, type, write, if you have like these mobile devices. And I think there is really there isn’t a lot of you know, there’s so much space in there. And we should really be much more welcoming to people that can’t, you know, sit on this nice computer have their three monitors, right, the keyboard and the mouse. And it’s really I mean, it’s really frustrating for me to write a blog post to make an update on Git, right, to make a PR.

[00:19:12] Jess Rose I’m not ignoring you. I’m just grabbing a book to see, so rude, isn’t it? Turning away? Oh, heck, I must have hidden it somewhere. But there’s a really fantastic book from the late 90s that Tim Berners Lee wrote about the process of inventing the web. But I’ve got sort of a tab in the book because he said, Oh, okay, we had to sit down we had to define the bare minimum. What is the minimum viable setup you need to access the web? He said, Oh, you need to, you need some kind of CPU, we need some kind of monitor some kind of display. And one of the things that they specified as necessary for the web was, you’re going to need a keyboard. I think that’s the point that sticks me again and again, where I think, but we’ve gotten past the need for keyboard in so many other spaces. Yeah, it seems a bit lazy to have not gotten past it in sort of the ability to do simple web development.

[00:20:12] Dr. McKayla Yeah, yeah, it would be so great. Like, I would benefit so much from it.

[00:20:17] Jess Rose Oh, just the guilt I’ve got right now. I’m just like, yes, yes, I’ll get back to work. But we do currently have learned, well, in the last cohort, we had a number of learners who were accessing the course, all via smartphones. So they would post and we’d love to see them post, screenshots of their code to see, hey, where’s this gone wrong, but it’s going to be folks screenshotting their phone screen, and just the implication of how challenging it would be to write, I’ve tried it to write a bunch of CSS on your phone, oh, the absolute, like the strength these people have in their hearts not to throw it across the room.

[00:21:01] Dr. McKayla Yeah, definitely. Definitely. So another question that came to my mind is now you have this experience of, you know, teaching really beginners, and also in a different space, it’s a space of you are, you know, like this, this teacher now, and they’re doing an online course. But I’m also very interested in how can we actually bring back or coming back to the managing position, right, how can we teach and mentor within a team, right? How can we do that for juniors? How can we do that for mid engineers? Who mentors and teachers, senior engineers? How is that all, you know, the dynamic in a team? And I was wondering if you have like some experience around that and some thoughts around that topic as well.

[00:21:47] Jess Rose So I was really lucky. I was on a team several years ago now out at FutureLearn. With oh, gosh, Nikki, What’s your surname? I’m so sorry. I swear I know it. I’ve just forgotten it, because I’m a bad person. And Belinda Sockington, who are both unreasonably brilliant and fantastic managers. And a lot of that work on that team was around, because I have FutureLearn was that it was a MOOC platform. How do we, how do we encourage learning? How do we incentivize it? How do we balance it? And really, what kind of landed for me is it’s an ongoing conversation between the folks running these teams, the individual people, I think it may be one of those issues where there’s just no one size fits all. It’s a combination of saying, Hey, we have these options. Here are some off-the-shelf learning experiences, with starting a conversation and keeping up a conversation of what do you want to learn, what works for you? What’s best for you? One thing that I’ve encountered a couple of times in my career, which I’ve had a really, really hard time with and my opinion on it has really radically changed, is every now and again, I’d meet somebody who’s sort of mid-level or senior, so they’ve they’ve gotten themselves into a secure role. They’re feeling okay with it. And they wouldn’t be that excited about learning where they said, Yeah, I just want to do my job. But I want to go home. And I think the first couple of times, because nobody tells you, but you’re not going to start managing people and get it right right away. I’m going to stay awake late tonight absolutely obsessing over the ways I’m still not doing it right. But back then I was thinking, Oh, how can I, how can I make this person care about their learning? And these days, I think with the, with the world having gotten much more stressful, and me having enough experience to see that I think now that I was wrong. These days, when I meet somebody who’s like, well, I’d like to do my job. I’d like to do a good job at my job. And I’d like to go home, I don’t really need to move up. I don’t really want to stretch and learn more. I’ve gotten, yeah, like, that seems increasingly chill. I think it might be cultural as well, I think. I’m from the States originally. And I think there’s quite a bit more fear around employment in the States. Almost everybody can be fired at any time and that makes everything very exciting. And generally your health care is associated with your employment. So I think I see when I was younger and based in the States, there was a lot more. Of course, you have to keep learning, of course, you have to keep running, you have to progress. Otherwise, something bad could happen. And yeah, I think I’ve just gotten increasingly excited to see people set boundaries around where they put their learning and where they put their interests. Yeah. Yeah, that’s a very strange take for a teacher.

[00:24:47] Dr. McKayla Yeah. So actually, I was talking to Cat Hicks, just a couple of weeks ago. Yeah. And so we were talking about learning debt. And this whole topic brought us to something where I think, you know, learning is often something very externalized, right, where you say, Oh, I’m learning, let’s say I’m learning React, or now I’m learning Remix, right? So maybe the newest framework or, you know, a new a new approach for DevOps or whatnot, right? So it’s something that’s out of what you’re doing right now. And it’s a new technology, very technology-oriented as well, whereby I think at the company, there are so many, a little bit more how to call it but informal, or, you know, a little bit more tactic, learning experience that you actually have every day, right, which is, how do I communicate with this new person on the team, right? How do I, how do I understand parts of this codebase? Can we change the architecture for that without breaking something? And all of these are also learning experiences, which we are often not declaring as that right, so we are not saying, oh, you know, McKayla, today learned about new ways to do this architecture for us or to refactor that code, or, you know, she did, she learned about how this API works over there that she hasn’t worked about, right? This is very often not, I don’t think it’s so visible in the learning experience than if I would say, Oh, me, hey, let’s sit down and learned React. Yeah, you know.

[00:26:25] Jess Rose And I think that’s really valuable. Because even when you say something, somebody say, I think, oh, you know, I’m just going to chill and do a good job. And it’s so easy to generalize about brains and learning to, say, Oh, we know what we know about learning. In so much as we’ve learned anything about learning like self-assessment’s messy, the study of, I’m not nearly clever enough to have a good handle on neuroscience and learning. But there’s actually a fantastic researcher and author, Dr. Barbara Oakley, who does a lot of work on learning how to learn. And she’s been doing some work with Zack Caceres who’s a programmer, and I’m not going to tell, talk out of turn. But I believe they may be launching a project around how we learn programming skills relatively soon.

[00:27:11] Dr. McKayla Yeah, nice. Yeah.

[00:27:11] Jess Rose But we’re primates in changing environments. Even if we don’t think about it as learning, we are getting new situations and new stimuli, just like you said, I’ve got a new teammate, I’m going to learn to work with them. Oh, I’ve got this API. Oh, I finally understood what’s going on under the hood. Regardless of whether or not we’ve set ourselves a mountain path to hike a declared learning journey, there’s still learning happening. Yeah.

[00:27:37] Dr. McKayla Yeah. And I think that those chill folks, how you call them, right? Maybe they have also more capacity to actually see things that are, you know, people that are very on their journey of, oh, I want to learn React and the latest, you know, whatever, technology comes out right now, maybe don’t have the capacity to see, for example, oh, you know, now that the market changed a little bit, budget shifted, we have to work a little bit different with this team, or, you know, how can we make sure that our deadlines are, you know, approachable, and so on? So, yeah, I think learning really happens in so many forms. And, yeah.

[00:28:14] Jess Rose And I, yeah, I’ve always been really excited about that as well. I think resilience is undervalued in teams often. Sorry, this isn’t very confident or it is not very definitive, but I’m going to waffle about my biases as part of this. I really like thinking about resilience in individuals and in teams as a resource available. And I like thinking of people as resources, but like, someone being rested, somebody having the capacity, somebody being ready for a little tiny crisis, or a little weird thing. That feels like a resource right there. But I think often we really lean on productivity so hard. How can we get. what kind of developer experience tooling can we use to get 20% more? How can we make sure people are focused? How can we cycle our meeting? And we’re so focused on developer productivity and the productivity of technologists, I think we often sacrifice that flexibility and that resilience of having somebody who’s not under these productivity pressures to such a high degree. Like, we learn better when we’re chill.

[00:29:25] Dr. McKayla Yeah, yeah. And I think it brings us back also to, there was this blue code, right? People that are taking on responsibilities, right, blue work, sorry, blue work, that was what it was called, right? But people that are taking on some invisible work that are, you know, good for the team. And, and so yeah, I think this also for teaching, mentoring, learning, I think this can be one thing, and obviously, we shouldn’t get outdated too much. And, but I also think that it’s not changing every minute, you know, like, sometimes we believe, or we were made to believe, or this story lines around time, Oh, my God, you know, if you’re not doing every day something and..

[00:30:11] Jess Rose What do you mean you’re not using blank? I’m like, look, I’m very old, and I’m very tired. Like, I’m good.

[00:30:18] Dr. McKayla I think it’s totally fine, right. And there are a lot of technologies, that I mean, if you’re working on PHP, you know, a lot of the web runs on PHP, and it’s still, you know, a good technology, and it’s okay.

[00:30:33] Jess Rose Like, if you want to stretch a little bit, getting into some Laravel is really, really exciting. But if you write PHP, you can hang out and get better at the core stuff of what you do. And do a good job. Like, you don’t have to run as hard as you can, as fast as you can forever.

[00:30:51] Dr. McKayla Yeah, I think they’re, they’re, you know, good choices to make. And I’m definitely for growth and for learning. But sometimes people are just burning, you know, mental calories. I learned so much. I mean, I’m actually a learner, right? I love to learn. But most of the stuff that I learn, I never used. It’s not very productive, right?

[00:31:16] Jess Rose Yeah, but not sorry, you’ve invited me on here. And I’m just up here ready to blow you. But yeah, this sort of cult of productivity, not that you’re espousing it makes me very, very, and when I talk to new learners, and they say, oh, okay, I need to learn this, and this, and this, and this, and this, and this. And I’ve heard these words, and I need to learn this. I’m like, Babe, you can, you can show we can all chill. Like, we don’t have to learn any frameworks yet. We don’t have to learn any ops yet, we can just chill and learn the core stuff. And as these are like, one thing I really like to encourage, especially with new learners, or learners new to a specific space, is to go ahead and get some kind of digital or some kind of physical space where you can dump stuff. Some people like Notion, I hate Notion a lot. I quite like Obsidian. I don’t care what you use, as long as you’re happy about it. As you’re seeing all these terms, just chuck them in a big doc. Okay, well, I keep seeing Angular, I know Angular is a thing, should I learn it? Don’t worry about whether or not you have to learn it next, just go ahead. And when you see an article about it, throw it in the slush pile. I call it my link dump for early learning. And that means once you’ve got through the foundational stuff, you say, Okay, I’ve learned enough JavaScript where I can write. And I like setting these little tiny interim goals to say, Well, I’ve learned enough JavaScript where I’m able to make simple bug fixes in this open source project I was interested in. I’ve learned enough. And one thing I’m excited about is the The Art of Learning code, or the art of reading code, which is something Felienne… is an academic who’s done a lot of work in the space.

[00:32:59] Dr. McKayla She’s from Leiden University.

[00:33:01] Jess Rose Yes. You’ve talked to her already. I bet.

[00:33:02] Dr. McKayla I did my PhD with her in the same room. Roommates. Yeah.

[00:33:06] Jess Rose Did you? Did you?

[00:33:06] Dr. McKayla Yeah, we were roommates. Yeah.

[00:33:07] Jess Rose Oh, is she just as delightful to study with?

[00:33:10] Dr. McKayla Yeah, she is wonderful.

[00:33:13] Jess Rose But yeah, so really getting through the basics of well, I set out to do X, I’m doing X. Now it’s time for me to go look through my link dump file, and see, wow, it looks like I’ve got like 40 different articles about Angular. Maybe that was important that that’s enough for what I want to learn next. Yeah.

[00:33:34] Dr. McKayla Maybe something else that comes to my mind here is also that I think fundamentals are really important, right? So I like for example, the approach of Dan Abramoff, right? He has like this course of chess JavaScript, which it means that you’re not starting with React, right? You’re starting with JavaScript and with the fundamentals around it, and I wouldn’t say it’s really a course for really real beginners. But it’s like if you got a little bit of your hands dirty around JavaScript, it’s really nice to go in and then check. Did I actually really understand what’s you know, what’s happening here? And then if you have these fundamentals, I think it’s so much easier to build upon that dump. And dive into React or whatnot, right? Whatever technology you want to add here.

[00:34:21] Jess Rose I think this comes back to something I’ve been thinking about a lot in how we learn and teach. But like, where we abstract things out. Soin the boot camp, we’re using Free Code Camp to teach, which is a, it’s an in-browser sandbox, you don’t have, and they’ve just come out with a new beta curriculum for web development I’m in love with. And it previews that these are files and that you have to link to these files. It is very, very good. But it’s still a sandbox, it’s still an abstraction. And the places we tend to send learners next are things like, Okay, we’re going to head over to CodeSandbox, we’re going to head over to Glitch which are still abstracting away a lot of really, and then even when you look in to professional tooling and frameworks, they say, Okay, let’s get into React. A lot of the power behind these frameworks are that they abstract away or that they compress, or they obscure or or smooth over some of the fundamentals of how we work with the core technology, maybe JavaScript or the way, Tailwind is a weird abstraction of the things you’d like to do with CSS. And I don’t have a problem with, I think it’s a teacher, I’d have a hard time having a problem with abstraction. But I think that thinking really carefully about how we do this, when we abstract things , and how we signpost what’s been taking, or what’s been added gets to be really valuable.

[00:34:47] Dr. McKayla Yeah, I think so too. Yeah. When I was starting to learn programming, I struggled a lot with abstractions because I just wanted to know, or not only with abstractions, but also like, there wasn’t a lot of abstractions. It was actually very, very raw, right? It was like, Oh, you have an Eclipse IDE open and you’re writing Java code. Bbut then you have like, oh, let’s say, you know, public wide string, main, whatever, right? And it’s just like, you just do it, right. And I’m like, why? What does it mean, don’t worry about it.

[00:36:22] Jess Rose And then we’ll cover this later. And so by the time, we will have covered it, yeah… Having been a linguist, I fear that I mentally map language learning to programming language learning, even when it might not be entirely suitable. But I see this happening in human language education as well, where we say, okay, cool. Here’s how, we keep we start people in the present perfect tens for a lot of languages, I see the cat, I drink the water, I walked to the store. And we don’t send them into a present perfect world. And I think that’s true with programming as well to say, Okay, well, we’re going to give you this sandbox, or we’re going to give you this framework, which abstracts away a lot of the complexities of the grammar or the the nuance of, and I think it’s really valuable to talk about the culture of the language we use around programming and really the culture of, of the structures we build, because it’s not transparent to people. I met with a learner in person, what a delight, in person last week. And without thinking about it, I said, yada yada yada bikeshedding. And thank goodness, this learner was confident enough to be like, cool, what the heck are you talking about? I was like, oh, gosh, that’s just something we say. We say it as though everyone’s going to understand it. And it means to get sidelined to get distracted with little unnecessary details. Just like okay, cool. You should just say that, it’s less complicated.

[00:37:55] Dr. McKayla Yeah. I think it’s not always that easy to be always aware of how you do it. But I recall the time that I started at Microsoft, and, you know, when you start there, it’s full of acronyms. And they mean, they mean something completely else inside Microsoft and what it would mean outside, and it really takes quite some time. And then a lot of people get very blind to it, and you know, just start using it as well. And you know, you start talking this gibberish. Nobody else can understand. Yeah.

[00:38:32] Jess Rose But like, from a linguistic perspective, that’s because that’s identifies you as a member of the in-group, doesn’t it? How fascinating. Yeah, incredibly interesting. Oh, no, no, I absolutely refuse to spend the next three days hyperfocused learning about weird Microsoft acronyms. It’s so tempting.

[00:38:49] Dr. McKayla Yeah, there are a lot. But I think it’s the same with code reviews, right? And with sometimes how people say, oh, you know, we have this style of giving feedback to each other. And in my code review workshops, I always talk You know, I always try to have people come to an agreement that we need to use language and also, you know, phrase that in a respectful way, that’s not only for the internal, you know, internal team to understand. Because there are newcomers, you know, in the team, maybe somebody will look at that, what you wrote two years from now, right, and still should be able to understand it. And so I think it’s really good if we be clear about those bridges that we built that, you know, are this internal behavior and language that we are using that it’s only, you know, it’s an insider joke, and so on.

[00:39:47] Jess Rose Yeah. Yeah. And I think we’re often really chill about that in tech. Yeah, oh, here’s a glossary of technical terms you need to know to do the thing. We’re, we’re cool about that. There seems to be a bit more resistance around when shared language or shared norms, or shared language structures around things like code reviews are proposed because we don’t need that we know how to talk to each other. I hope I’m not putting you on the spot. Are you one of those lucky people who speak like nine languages?

[00:40:15] Dr. McKayla No, not nine.

[00:40:15] Jess Rose Oh, only five?

[00:40:17] Dr. McKayla Maybe, yeah. German is my mother tongue, right? English, Dutch, Italian, and a little bit of Spanish.

[00:40:28] Jess Rose A little bit of Spanish. Look at that. The fantastic thing about chatting to many folks from Europe is, is y’all always have this very, very beautiful, very casual, like humble brag at the end, you like, you know, just a little tiny bit of Croatian. I’m terribly jealous. Yeah, like recognizing that folks aren’t going to be coming to, coming to these code reviews. And I really liked that you highlight that they’re going to be coming to the uncoupled in time. I love this idea that when you leave a code review, when you leave feedback, when you leave a pull request, when you leave code, you’re leaving a little artifact of understanding behind. So to say, Cool, we’ve standardized how we talk about these, we’ve created a shared language for them. Because when we go into the far scary future, we want these to still make sense.

[00:41:23] Dr. McKayla Yeah, I think this is really important.

[00:41:26] Jess Rose But also making them like giving a shared language around, hey, maybe English, or if we’re doing the, if we’re doing the code review, in Dutch, I’m in a bit of trouble. But maybe the language this code review is in is your second or third or fifth? Let’s go ahead and have some shared language have some shared structures around feedback to lower the cognitive load? Yeah, well, can we talk about cognitive load? I imagine you’ve done it tons of times on the podcast. I imagine many programmers are familiar with it.

[00:42:00] Dr. McKayla Yeah, we also have to be a little bit careful of the time now. But maybe the last thing that I want to add here is I’m writing a book on code reviews, right?

[00:42:10] Jess Rose Are you?

[00:42:10] Dr. McKayla Yeah, I’m right now in the middle of the feedback section, right? So how to give feedback, how to give respectful feedback, and how to communicate with each other and also cultural right? So how do we deal with, it gets really hairy there, right? So yeah, what are different cultures are expecting, what’s respectful there, you know, how much you know, how harsh should a feedback be? Or can it be or, you know, what is seen as polite and so on? And this is not only, it’s not only, it’s not one standard thing, right? It depends on who’s on the team, what’s the background? What’s the culture? But I think the expectation, setting the right expectations, and, you know, explicitly stating that, and talking about that, reflecting on that, and, you know, learning how others see those things and learning how, you know, like, if I would talk to you I’m originally from Austria lived in a couple of countries, right? You’re from the States you’re, you’re in the UK now, right?

[00:43:12] Jess Rose I am, yeah, everything’s just fine here. Very chill. Not weird.

[00:43:10] Dr. McKayla Yeah. And then maybe we have another person from Croatia and then somebody from India, right. And so I think it would be really important for us to talk about how we understand different terminologies, how we understand different you know, expressions in my career workshops, sometimes I have discussions about looks good to me. And I love those discussions because, you know, it’s just a simple term looks good to me. Most of the time, people just, you know, have the acronym for it, right?

[00:43:47] Jess Rose Like it’s the thumbs up emoji in my head.

[00:43:50] Dr. McKayla Exactly or you know, LGTM, right? And then some people are like, oh, yeah, this means you know, that I looked through it and you did a good job. And then the other person has no, you know, looks good to me means that you haven’t looked at my code.

[00:44:07] Jess Rose You just glanced at it.

[00:44:07] Dr. McKayla Yeah, you just want it out of your way. Yeah. And the other person says, Oh, this means, I don’t care.

[00:44:07] Jess Rose Sometimes, sometimes.

[00:44:16] Dr. McKayla And having those discussions in the team, you know, and understanding where everybody is coming from, and that they actually use, you know, one simple terminology. And everybody on the same team understood something else about it, I think it’s so valuable, right? And only by these discussions, you know, we can really understand what’s behind those terms and the way that we are communicating. But I’m also getting a little bit carried away.

[00:44:45] Jess Rose No, no. So I’m going to ask you about your book. And yeah, I’ve just had a friend tell me that there are some questions you’re not supposed to ask about someone’s book. So I won’t ask any of those. Instead, I’ve been told you’re supposed to say, I hope it’s going well. I’d like and I think it might be useful for hopefully some of the audience as well. I had an idea for a book that sounded really fun in my head. And I’ve sort of broken it down into chapters into essays and trying to write a couple of chapters. And my goal in writing a couple of essays is I’m trying to talk myself out of writing a book.

[00:45:22] Dr. McKayla Yeah, I’ve heard that. Yeah.

[00:45:23] Jess Rose Do you have any advice for not, like, it’s the worst. It’s the worst idea ever. No one wants to write a book like, please, please, please.

[00:45:32] Dr. McKayla No, I don’t have.

[00:45:32] Jess Rose No, I want to know what you’re doing.

[00:45:34] Dr. McKayla But I saw on Twitter that you said that and I thought, like, yeah, you won’t be able to not write a book with this approach, right?

[00:45:42] Jess Rose I love that it sounds like a th reat, where you’re like, you’re going to write that book.

[00:45:45] Dr. McKayla Yeah, it looks like. I think if you’re breaking it up in essays, that become more manageable. I think you will write this book. Yeah.

[00:45:55] Jess Rose But for our beloved audience, for your beloved audience, they shouldn’t write a book, they should, they should definitely do things that are not writing a book. Like, it’s a terrible idea, isn’t it?

[00:46:04] Dr. McKayla I can’t, I can’t say it’s a terrible idea.

[00:46:06] Jess Rose Are you enjoying it?

[00:46:08] Dr. McKayla I don’t think it’s a good idea. But I think a lot of people would like to write a book and I would be the last person that would discourage them. Because I was always discouraged to write a book, right? But I think I know what mess I got myself into.

[00:46:25] Jess Rose That’s what I’m looking for, there we go.

[00:46:26] Dr. McKayla I would just tell the people that you’re getting yourself into a big mess. But it’s okay. You know, it’s okay. I think people can write books, and people should write books.

[00:46:36] Jess Rose The world is messy. It’ll be fun. Oh, no, this is the opposite of what I was looking for. But it’s so delightful.

[00:46:42] Dr. McKayla Yeah, well, Jess actually, this brings us to the end of our show, I really enjoyed talking with you about all of that. And I think we should talk about cognition and cognitive load, and you know, all of that. So maybe I will invite you again, to another session

[00:46:58] Jess Rose I’d love to come back any time. But I’ll also pass you some contacts for folks who are much better at this than I am, I would just go back and be like, so books. And really, your audience deserves better.

[00:47:13] Dr. McKayla Okay. And we will both all the things that we talked about down there also, maybe the Twitter handle or LinkedIn profile or whatnot, from the person that you mentioned in the middle, where you forgot the last name, I put it there. So she will be there as well. And then, yeah, so is there something that you want to wrap this episode up? Or?

[00:47:36] Jess Rose Oh, gosh, can I bully your audience? Is that doable? Is it permitted? I’ve been doing advice calls all this week. And the big thing that I keep coming back to when I chat to people, I do do them just to be mean to people who are smarter than me is right now everything, everything is just so big and so loud and so stressful. One thing I’ve really enjoyed exploring with people is looking at ways that what they have to do, what they think they have to do can be smaller and softer and quieter. And I think that yeah, I’d love to gently bully folks to consider how what they need to do could be a little less. Maybe you don’t have to write that book. It can just be an essay.

[00:48:24] Dr. McKayla Yeah. Yeah. I like that. I actually did that this week with myself and just gave myself permission to let go of a couple of balls that I was juggling. And I think it’s delightful. We should really do that. And I think it’s it’s the time that we are many people needed. Not everybody, right. I think a lot of people needed.

[00:48:41] Jess Rose There’s going to be one person out there who’s having a real good week. I just haven’t met him.

[00:48:46] Dr. McKayla Or yeah, or that cat very nicely distracted by all of the work and don’t have to think about the stuff that’s going on. Yeah. Okay, so Jess, thank you so much. Thank you. It was really a pleasure talking to you.

[00:49:01] Jess Rose Thanks so much. I’ll let you go and thank you again. I won’t get into a thank you loop with you.

[00:49:06] Dr. McKayla Okay, bye-bye.

[00:49:06] Dr. McKayla This was another episode of the Software Engineering Unlocked podcast. If you enjoyed the episode, please help me spread the word about the podcast, send episode to a friend via email, Twitter, LinkedIn. Well, whatever messaging system you use, or give it a positive review on your favorite podcasting platforms such as Spotify or iTunes. This would mean really a lot to me. So thank you for listening. Don’t forget to subscribe and I will talk to you in two weeks. Bye

 

What hinders your career as a developer? – Mindset.

In this episode, I talk to Dagna Bieda. Dagna is a software engineer turned career coach who has mentored 50+ clients, some of whom worked at big brand names (such as LinkedIn, Amazon, Google, Disney), as well as much smaller businesses. Whether it’s for promotion, salary increase, landing a new job, or becoming a CTO, she’s committed to helping her clients reach their full potential.

We talk about:

  • how Dagna experienced a plateau in her career as a software engineer
  • what she did to overcome this stagnation
  • Cultural differences in the US and other countries
  • how she helps immigrants like her fit into their American workplace
  • and common limiting beliefs engineers have and how to overcome those.
Dagna Bieda Engineering Coach

This episode is sponsored by Tonic.ai – where your data is modeled from your production data to help you tell an identical story in your testing environments.

Links:

Subscribe on iTunes, Spotify, Google, Deezer, or via RSS.

Transcript: 

[If you want, you can help make the transcript better, and improve the podcast’s accessibility via Github. I’m happy to lend a hand to help you get started with pull requests, and open source work.]

[00:00:00] Dr. McKayla: Hello, and welcome to the Software Engineering Unlocked podcast. I’m your host, Dr. McKayla. And today I have the pleasure to talk to Dagna Bieda. She’s a software engineer turned career coach for software engineers. She’s been coding for over 10 years and has been a coach or has been coaching for the past two-plus years.

[00:00:24] Dr. McKayla: And today I will learn everything around how to get a job, how to be successful as a software engineer, and how to advance your career. But before I start, let me introduce you to an amazing startup that’s sponsoring today’s episode, Tonic.ai, the fake data company. So what does Tonic.ai do? I’m sure you know how complex and cumbersome it is to create quality test data.

[00:00:51] Dr. McKayla: It’s a never-ending chore that eats into valuable engineering resources. Random data doesn’t do it and production data is neither safe nor legal for developers to use. What if you could mimic your entire production database to create a realistic dataset with zero sensitive data? That sounds amazing, right?

[00:01:10] Dr. McKayla: Tonic.ai does exactly that. With Tonic.ai, you can generate fake data that looks, acts, and behaves like production data because it’s made from production. Yet, Tonic.ai guarantees privacy so your data sets are safe to share with developers, QA, data scientists, heck, even distributed teams around the world. Visit Tonic.ai to sign up today or click the link in the show notes to get a free two weeks trial sandbox.

[00:01:38] Dr. McKayla: Well, Dagna, I’m, I’m so excited to learn everything that, you know, you have been through. in your career as a software engineer and how you actually help software engineers get the most out of their career. So can you tell me a little bit, how did you go about to this shift from, you know, being a software engineer, yourself to being a full-time career coach for software engineers? Why did that happen and how?

[00:02:03] Dagna Bieda: Absolutely. And first of all, thanks so much for having me on your show, McKayla. Essentially, you know, in my own career, I have seen some incredible accelerated progression in my own career. When I started programming, I went from a junior engineer to a senior engineer fairly quickly.

[00:02:22] Dagna Bieda: It happened in less than three years, which, it takes a lot more for a lot of engineers in our industry. And it was all because of the people that were in my corner that supported me, that mentored me. And because I was very relentless about asking them for feedback to tell me how I can improve, how I can do better.

[00:02:44] Dagna Bieda: And as I kind of like, went up in my career in my senior engineering role, what happened is I experienced this plateau, you could say. And I recognized, later on, you know, in hindsight that I was just working really hard on the wrong things, but I didn’t have that kind of support that I needed that would have showed me like, Hey, Dagna, what you’re focusing on is not going to take you to that next level.

[00:03:11] Dagna Bieda: So after having that aha moment, I recognized like, okay, I was going super quickly, advancing in my career in the early, in the beginning, because of that support. Later on, I didn’t have that support. I had to figure it out by myself. And so , it was so much slower of a process when I was trying to figure it out myself.

[00:03:32] Dagna Bieda: So I decided that, you know, this is a great idea for a business because not everybody, being a software engineer, has that support network that they could lean on. So I could step in and become that support network for my clients. And that’s exactly what I do today. And it’s just amazing. And I’ve helped so many clients, you know, I’ve had over the past three years that I’ve been coaching, I’ve helped over 50 engineers.

[00:03:59] Dagna Bieda: They had various backgrounds. Some of them work at fan companies. Some of them work for like small mom and pop shops, and they had experience ranging anywhere from 2 to 20 years of experience. Some were self-thought. Some had college degrees, some are boot camp graduates. And you know what I do right now as a coach and that lits me on fire and, you know, brings a lot of fulfillment to my life is to help my clients find that in their life and in their career.

[00:04:28] Dr. McKayla: Okay. And so, what does it take from a junior to become a senior? And why was there no support for you when you were a senior to get, you know, to the next level? Maybe what was your next level? Was it like a staff engineer that you wanted to become, or is it more in a managerial role that you wanted to develop yourself? So what’s the next, the next step?

[00:04:52] Dagna Bieda: I wanted to become a team lead and team lead is like a mix of both, right? On one hand, like from an HR perspective, maybe you are not on the org chart on top of like a team, but you are leading your team with your technical expertise. So like it’s a mix of the managerial and the engineering responsibilities.

[00:05:09] Dagna Bieda: The big reason why I had the plateaued is because I moved from Poland to the United States. And as an immigrant. I didn’t realize that, you know, the way I was thinking and going about work, while it made perfect sense back in Poland, it didn’t necessarily set me up for success in my American workplace.

[00:05:30] Dagna Bieda: And also like right now, a lot of my clients are immigrants moving from one country to another. And what I help them is to understand how their cultural upbringing affects their performance at their workplace. Because for me that was one of the blockers, right? I had to really kind of like understand my new situation, my new culture, how I was fitting in what was stopping me, and for example, there’s this one situation that I can, that comes to mind is when, when I posted a joke in slack that I thought was super funny and, and being an Eastern European, we have this dark sense of humor.

[00:06:06] Dagna Bieda: And, you know, in this new American company, what happened was I was called to HR and I was told that that was inappropriate. And I was like, what? That was super funny. What are you talking about? So, that was like one of the things that I had to realize, like, okay, This is the type of sense of humor that just doesn’t go with my workplace.

[00:06:27] Dagna Bieda: So I can, you know, keep doing that on my own and private, but this is not going to help me in terms of work advancement, right?

[00:06:34] Dr. McKayla: So can you, can you go a little bit more into this in this cultural aspect, right? Okay. There are the jokes that obviously, there are cultural differences. What’s funny, what’s not, what’s inappropriate, right, and so on. But is there also like for leadership because you were talking about tech lead, right? So it’s, how, how can you show the outside world that you’re ready for it? Is there a difference in your experience?

[00:06:58] Dagna Bieda: Yes. So that’s another like cultural aspect, you know, like, there’s this specific tool that I use for analysis that helped me really map those differences. And it’s called the Hofstede model. And essentially, it has, like, this database that compares different countries on, like, six different dimensions, right? And one of the things for the United States specifically is that individualism is super highly rated, right? And Poland is more rated closer to being like a collective culture, right, where we work together towards success. And I can tell you, for example, there was this initiative that I was leading in my American workplace.

[00:07:45] Dagna Bieda: And what happened was I was talking to different people, different types of stakeholders. They agreed with me. So I thought, okay, if I have a buy-in, something’s going to happen now, right. Because that’s how it would have worked back in Poland, right? In the American workplace, I was expected to, once I picked up the initiative to lead it from end to end. And, you know, I wasn’t aware of that. So, you know, I got all the stakeholders on board. Everybody agreed to my idea and then nothing happened, and I got so frustrated. I’m like, why there’s nothing happening? Like, didn’t we all agree, should we all collaborate together? And because they didn’t realize that my cultural upbringing was different, nobody could give me that kind of feedback, right?

[00:08:29] Dr. McKayla: Yeah.

[00:08:29] Dagna Bieda: They just didn’t know how to support me there.

[00:08:32] Dr. McKayla: I think this topic is so interesting because right now I’m working on the book on code reviews and I’m working a lot about feedback and disagreements, agreements, and how to solve that, right, how to collaborate together.

[00:08:45] Dr. McKayla: And so one book that I’m actually deep diving into that I found really interesting was The Culture Map. I don’t know if you are familiar with, from Erin Meyer, and there she…

[00:08:55] Dagna Bieda: Oh, that’s interesting. Okay.

[00:08:56] Dr. McKayla: Yeah, you can have a look at it and she also looks at a different perspective. And one is, for example, agreements, how are people from different countries agreeing? And for example, Germany or Austria, right? It’s a little bit more collaborative or, you know, collective, right? Collective agreement.

[00:09:11] Dagna Bieda: Exactly.

[00:09:12] Dr. McKayla: It’s really, really important. So it takes a very long time until everybody agrees. And it’s a little bit an upfront process, right? Whereby in America, it’s more, well, one decision is made by the leader, but then this decision can also be questioned along the way, right? And so it’s quicker, quicker to get started, right? And one person brings up and says, okay, this is how we are going to do it.

[00:09:34] Dr. McKayla: And then people are working on this vision. This is how she explains it, right? But yeah. And then over time, you can actually challenge that a little bit, right? You can say, but maybe, you know, we should change course because we have more information now and so on. And in Germany, it’s exactly the other way around, right? So we are investing a lot in this process of collective agreement, on this is the right way to go. But because there’s a lot of, you know, a lot of time and information that goes into this process, it’s really hard to challenge that later on, right? So after three months of discussing that we are going to do that.

[00:10:09] Dr. McKayla: It’s really hard to say a month later, oh, maybe you should change that again, which I think is perfectly fine in America. I don’t know. Can you see that as well? Is that something that…

[00:10:20] Dagna Bieda: Oh, absolutely. Yeah, absolutely. And another interesting thing is like, for example, in terms of the short-term versus long-term orientation, in the United States, the culture as a whole is on the Hofstede model described as a more short-term oriented. So the company would be more like working towards your quarterly goals, right? And when I work, for example, with some of my clients that have Asian upbringing and working in the United States, that their cultures tend to have this long-term orientation.

[00:10:51] Dagna Bieda: What happens is, for example, in an interview, whenever they present themselves, they’re talking about, you know, building a solid foundation for a long term. But what happens is. American companies don’t necessarily value that, right? Because, and they even have this, this saying here to hit the ground running, right? So when I work with my clients, I tell them, look, if you’re starting to work in a new workplace, American workplace, you want to present yourself as someone who’s operating fast and can bring results really quickly because of valuing of that short term results rather than long term.

[00:11:27] Dr. McKayla: Yeah, yeah, yeah. I can totally see that. So you are working as I understood it, you’re working with a very range of experiences, right? So you said people are coming from boot camp, but it’s just coming from boot camp with no experience and want to go into the workplace or is it more, are they already, you said two years, something like this.

[00:11:48] Dagna Bieda: Yeah.

[00:11:49] Dr. McKayla: Is it really an even distribution here or do you see that it’s cooling in one direction, right? More the junior engineers in the first, let’s say, five years or more the senior engineers or midterm, maybe?

[00:12:02] Dagna Bieda: I would say that the majority of my clients are the mid-level professionals and the more senior professionals that are kind of like finding themselves a little stuck, maybe not sure about their next step.

[00:12:13] Dagna Bieda: And they’re looking for, you know, figuring out first of all, how are they stopping themselves? Second of all, how to find fulfillment in their career rather than chasing money or promotions. And, you know, the truth is there’s, to my knowledge, nobody else that offers the type of services that I offer, which is working on the engineering mindset for success, right?

[00:12:36] Dagna Bieda: And you know, what got you to that senior engineer position was very likely your technical foundation. And I do not work on that technical foundation while having been a software engineer myself, I can definitely send my clients some pointers, like what are the gaps that they have in their skill set that they should, like, fill up in terms of you know, career advancement, but what I really am passionate about and what I really love to focus on is that mindset piece, right? Like, what kind of blind spots do you have? What kind of limiting beliefs do you have? I actually like to say that I moved from programming computers to reprogramming human minds. And it really beautifully describes what it is that I do, because once you change your mindset, I put it this way.

[00:13:21] Dagna Bieda: How you think is how you act. And how you act is the results that you’re getting then from, you know, the reality, the real world.

[00:13:31] Dr. McKayla: Yeah. Can you tell me some limiting beliefs? I also regularly reflect on mine and, right now, you know, I’m also in a, this state where I think, because of the pregnancy and the very new birth, I think this is such an inward-facing period in my life again, right, where I’m thinking, like, what are the beliefs that I have, and that are holding me back and so on. I would be really curious, can you give some examples of beliefs that engineers have, maybe that you have seen patterns?

[00:14:00] Dagna Bieda: Absolutely.

[00:14:01] Dr. McKayla: Yeah, that hold them back.

[00:14:02] Dagna Bieda: There are two that are super common and super popular. Number one is believing that your work speaks for itself, which it doesn’t. It does not. Like, okay, if someone else works on the same code base with you and they can look at your code, they could see the value that you bring to the table if they put in the work and effort to actually go into the code, look up what it is that you committed and, you know, have some thoughts on that.

[00:14:28] Dagna Bieda: But, in order to be successful in an engineer’s role, what you really have to do is market yourself. You have to talk about your achievements and accomplishments and not expect everybody in the company to just know what it is that you’re doing, because people just don’t know. They have their own work that they’re prioritizing.

[00:14:44] Dagna Bieda: And it’s very critical to figure out if you have that limiting belief of work speaks for itself because again, it doesn’t. That keeps a lot of talented engineers stuck in their career. That’s number one. The second one, which always cracks me up, but I used to think that way too. There was a moment, and I have to be honest with you, there was a moment I thought the same way. And the second limiting belief is essentially, that you are surrounded, as an engineer, with idiots that just don’t want to listen to your amazing ideas. And here’s the thing, whenever, as an engineer, you have an incredible idea and you want to pitch it. You want to get people on board.

[00:15:25] Dagna Bieda: It’s super important for you to communicate about it in a certain way. You have to be able to negotiate. You have to be able to like really describe it, but describe it in terms of the priorities of your stakeholders, right? So if I’m going to, and I’m guilty of that as well. Like, there was this two projects that I worked on in my most recent engineering job, and I was responsible for taking care of a mobile app.

[00:15:48] Dagna Bieda: And it was a pain in the butt that the build of the app was taking a few minutes, you know, and I just felt it was so inefficient. So I went ahead and I refactored how this particular app was built. And I reduced the build time from few minutes to, like, 30 seconds. And I was so proud of myself, you know, I was so like, yes, this is amazing in reality, what happened is, that what I did that work that I did, impacted my life and one other engineer. Nobody else cared. It didn’t matter. Then I had a second task or project that I worked on in the same company, which was creating a deliverable for a client, super boring, a lot of copy and pasting, a lot of like following steps. I did not enjoy doing that at all, but guess what?

[00:16:36] Dagna Bieda: Whenever it was deployed and the client could spread the mobile app to their own client base, I got praise from the sales representative from our BA, from the project manager. My tech lead was like, wow, Dagna, that was a super fast turnaround. You know, everybody across the organization was like, yay, success.

[00:16:57] Dagna Bieda: And I’m thinking to myself, Wow. I would have never in a hundred million years figured this out on my own. If, if you ask me as an engineer to like put a value on this project versus that project, I would’ve thought that the refactoring was better. So here’s long story, but essentially what I’m trying to say is, it’s very important to understand how what you are doing trickles, like, how what you’re doing fits into the business as a whole, the business that you’re working for and how to communicate about it. That’s the, really the key of what I was trying to say here.

[00:17:35] Dr. McKayla: Yeah, I think that’s really, really important, but I also found myself working at companies where. You are assigned things, right? So you’re not really asked for your opinion. if this is now really helpful or not or, or something like this. And then maybe reassigned as well, right, which I think there are, there are several impacts to that. First of all, what would be your advice for people that are assigned projects where they also know maybe doesn’t look like this has a big impact on the company, right? So it’s also limiting my ability to advance my career here. What should you do? How do you communicate about that? What’s your advice?

[00:18:18] Dagna Bieda: Yeah, we’re kind of going back to, you know, to that communication piece, right? So, first of all, one thing that I want to share the assumption I’m coming here up with is that whoever assigns you that work is not a mind reader, so they would not necessarily have your priorities, your career priorities in mind.

[00:18:37] Dagna Bieda: So it’s important to, whenever you are asking for work to kind of like be proactive and say, Hey, I am really working towards becoming, let’s say a staff engineer, becoming a team lead, becoming an engineering manager, can you help me out and assign the kind of work to me that will help me achieve that goal, right?

[00:18:58] Dagna Bieda: Asking for that help and support because most of us are nice and friendly people, and we want to help. But we don’t always know what’s the best way to provide that help. So being kind of like your own advocate and talking about what it is that you want to do is really critical here. A second thing is, you know, whenever you’re in those one-on-ones with your manager, is to really ask for feedback. How are you doing, how you could be doing better, and creating that safe space for feedback. You know, something that is my strength actually, and really helped me with accelerating in my career early on was that relentlessness in asking for feedback. Like, I had this team lead that worked with me that helped me become a senior engineer because he kind of vouched for me in the meetings that I wasn’t part of.

[00:19:53] Dagna Bieda: And he really said like, Hey, she’s ready. She can handle it. She can be a senior engineer. I think she’s ready. And that’s what got me the promotion. But when him and I worked together, I was telling him, look, I really want to know. Don’t worry. You’re not going to hurt, hurt my feelings. I want to advance, I want to be hitting the ground running, and I want to really work on the things that are holding me back.

[00:20:16] Dagna Bieda: And, you know, one of the critical pieces of feedback that he initially didn’t want to give me, because it felt like maybe he would hurt my feelings or maybe was too much. I don’t know. But after I was pushing and pushing for that feedback, he essentially told me, Dagna, fast is great. But reliable is better.

[00:20:35] Dagna Bieda: And that advice changed how I was thinking about writing code, because I was really prioritizing being fast, delivering as soon as possible, right? But sometimes my fast solutions were not fully thought out. And a senior engineer really has to have that understanding of how the engineering decisions impact business, the team and what it is that, that they’re trying to accomplish as a team.

[00:21:03] Dr. McKayla: Yeah, I’m thinking back of a time, right, where I think it’s totally true that we have to go and advocate for ourselves, but I also wonder how many people are a little bit stuck in that, well, this is what the business needs, right? I understand that you want to advance your career. You want to become, you know, a senior engineer or a tech lead or whatnot.

[00:21:27] Dr. McKayla: You know, saying that the project doesn’t seem to have such big impact, right? And big impact, I think has to do with the stakeholder. Who is it visible to, right? Who is going to see and hear your name and, and so on. I thought, I think there’s a little bit of political background towards that as well. Have you worked with people that are just really stuck in a situation where there is nobody that really advocates for them too much, or they are assigned a project that’s, you know, low visibility and they’re stuck there. Would you say the best is to move companies or?

[00:22:01] Dagna Bieda: The short and sweet answer is yes. And, you know, in the very first meeting that I have with my clients whenever we start our coaching sessions in the program, what we do is we figure out what are their specific life and career goals, and what are their values and, how their current workplace supports those values. And then we measure them in a specific way. And after that, specific exercise, we’re able to confidently say whether it’s worth staying in that place or if it’s time to move on.

[00:22:38] Dr. McKayla: And so, whenever I see, like, in my Twitter bubble, right? I’m also very much in the American, you know, world somehow. And everybody is like, oh my God, the marketplace is, or the market is so hot now. And, you know, jobs are everywhere. I don’t know in Europe, I don’t feel that way.

[00:23:00] Dagna Bieda: Got it.

[00:23:00] Dr. McKayla: Is, is it like this? Do you feel like right now, it’s so hot and everybody can, you know, change their career in a second and get better and you know, why would you even stay there? I feel like even if you have a good place, let’s move because you can make more money and so on, which is a very different mindset.

[00:23:18] Dr. McKayla: I don’t see that here in Europe so much. It doesn’t feel that hard or it also feels like if I’m at the good company and, you know, I make a market okay salary, I don’t feel that people are looking forward, changing every one and a half, two years, more.

[00:23:34] Dagna Bieda: Yeah. So two years is very common for people who are very ambitious.

[00:23:39] Dagna Bieda: I want to try to see how different companies do different things and gain those experiences across a variety of industries or companies of different sizes. So, two years is definitely something that’s seen as fairly normal. And I feel like you touched on an important subject there, it’s very important to realize that the European job market is much more fragmented, right?

[00:24:03] Dagna Bieda: Because we have different countries, different cultures, and it’s not as easy to, you know, have access to all those opportunities. In the United States, it’s way more streamlined because you know, it’s one country and people mobility is also completely different. So like if you live in LA and then next year you get a job in New York, it’s much more likely that you’re just going to pick everything up and move for that job.

[00:24:30] Dagna Bieda: In Europe, we are not like that. so it’s more like choosing a town you want to live in, and then you find a job within that town, say, for example, right? So in that sense, we have just different priorities in Europe, and there are different priorities here in the United States, and that impacts that job market, absolutely. With that being said, with the COVID, the pandemic, and the acceleration of the remote workplaces, there’s more and more opportunities for the Europe software engineers, for example, or anyone else really to access those American jobs. I cannot think of, like, anything in particular, but there’s more and more companies that are supportive of those remote jobs and help pair American companies with offshore workers.

[00:25:18] Dagna Bieda: And it’s kind of like in that saying where Europeans work to live and Americans live to work. There’s definitely something in that, some truth to it. I mean, I remember when I moved to United States and I was, you know, trying to get my very first engineering job and, on the phone interview, someone would tell me, like, we offer three weeks vacation, we’re generous.

[00:25:42] Dr. McKayla: Yeah, it’s different.

[00:25:43] Dagna Bieda: Yeah, right? It’s different. It’s different. There’s so much more vacation time back in Europe, back at home. In the United States, even though they are coming up with, like, this unlimited time off policies it really depends on the company. Some companies are just trying to not pay you out the accrued time off.

[00:25:59] Dagna Bieda: So you have to like really be wary when you are verifying if it’s really unlimited time off. But with that being said, I had a client and she took like 10 weeks off within a year. So you know, there are companies that, yeah, there are companies that really kind of like honor that.

[00:26:15] Dr. McKayla: Okay. Okay. Well, I have a last question for you, actually, and it’s about code reviews because you were touching upon communication and also showing your work and what you are doing. How do you think can people use code reviews to do that, to accomplish that, to, you know, make their work a little bit more visible? Is it something that you thought about? How that fits together?

[00:26:39] Dagna Bieda: So in terms of code reviews, the advice that I really give to my more inexperienced clients who are earlier in their career journey is to not take them personal.

[00:26:51] Dagna Bieda: Just take it in as an information, as a guidance and, you know, earlier in their career, a lot of software engineers tend to take those comments, that feedback very personally, and they have their feelings hurt. But in reality, it’s just feedback. It’s just objective information that you can use to better yourself.

[00:27:11] Dagna Bieda: Now, in terms of my more senior client, their skills are at the level that, you know, I don’t see code reviews being very critical there because they already, you know, have mastered that technical foundation. So what I focus on really is those skills that are missing: the people skills, the communication, how you market yourself and all the things that we talked about today.

[00:27:34] Dr. McKayla: Okay. Okay, cool. So, Dagna, thank you so much. Maybe you can also tell us a little bit how people can follow your work can find you, and maybe something that you want to. You know, give on the way for the engineers on how to find the career or the next step that makes them happy.

[00:27:56] Dagna Bieda: Yeah, absolutely. So the best way to really get in contact with me is through my LinkedIn profile. You just can go to LinkedIn and find me under Dagna Bieda, D A G N A B I E D A. And then you can also go ahead to my website, the mindfuldev.com/podcast, and you’ll find there a case study. And that case study beautifully explains the process that I follow with my clients and how it helped them really level up in their career. For one client, it meant going from an underappreciated senior engineer to a startup CTO in three months. For another client, it meant moving from a senior engineer to a VP of engineering and innovation at his company. For another client, that meant doubling his salary as we work together. So, you know, if that case study is something that you’re interested in, you can then reach out to me and we can see if we’re a good fit to work together and how I can help you accelerate your career.

[00:28:57] Dr. McKayla: Okay. Cool. Thank you so much. Thank you, Dagna, for being on my show.

[00:29:01] Dagna Bieda: Absolutely. It was a blast. Thanks for having me, McKayla.

[00:29:04] Dr. McKayla: Yeah. Thank you. Bye.

[00:29:06] Dr. McKayla: This was another episode of the Software Engineering Unlocked podcast. If you enjoyed the episode, please help me spread the word about the podcast, send the episode to a friend via email, Twitter, LinkedIn, well, whatever messaging system you use. Or give it a positive review on your favorite podcasting platforms such as Spotify or iTunes. This would mean really a lot to me. So thank you for listening. Don’t forget to subscribe and I will talk to you in two weeks. Bye.

 

Improving Code Reviews with Github’s Copilot

How does GitHub Copilot and Codespaces help data scientists to write, understand, and review code?

Do not punish learning in software engineering teams

What does it take to foster a workplace culture where employees, specifically coders, have the liberty to learn without feeling punished for it by the system? Innovation is impossible without failure, but most work cultures suffocate creativity without realizing it.

In this episode, I talk to Dr. Cat Hicks, a data scientist, a behavioral scientist, and a creative entrepreneur.

We talk about:

  • how she deviated away from a traditional path of a researcher to start her company, Catharsis Consulting, 
  • how to foster a learning culture within your engineering team
  • what learning debt is and 
  • how learning debt hinders software engineering teams to reach their full potential. 
Dr. Cat Hicks

Today’s episode is sponsored by Codiga, a smart coding assistant and automated code review platform. Try Codiga for FREE!

Subscribe on iTunes, Spotify, Google, Deezer, or via RSS.

Transcript: Foster a learning culture in engineering teams

[If you want, you can help make the transcript better, and improve the podcast’s accessibility via Github. I’m happy to lend a hand to help you get started with pull requests, and open source work.]

Dr. McKayla 00:03 Hello, and welcome to the Software Engineering Unlocked Podcast. I’m your hosT Dr. McKayla, and today I have the pleasure to talk to Dr. Cat Hicks. But before we start, let me tell you about an amazing startup that is sponsoring this episode Codiga. Codiga is a code analysis platform that automates the boring parts of code reviews and lets you merge with confidence on GitHub, GitLab and BitBucket. I’ve worked with Codiga for around one year now, and I love how it guides me in discovering the, well, not so nice parts of my code base. But there is more: Codiga also has a coding assistant that helps you write better code faster. Find and share safe and reusable blocks of code within your favorite IDE on demand while you are coding. Codiga has a great free plan, and so there is nothing that actually stops you from giving it a try. Learn more at Codiga.io. That is Codiga.io.

But now back to Cat. Cat, or Catherine Hicks holds a PhD in experimental psychology and is a principal researcher in Team Lead at catalysis consulting. She has designed researchers at places like Google Khan Academy and co founded a startup that builds tools for software engineers, and she led multi institutional collaborations in online learning. So I’m super, super, super thrilled to have a cat here with me, Cat, welcome to the show.

Dr. Cat Hicks 01:30 Thank you so much. I’m really excited to be here.

Dr. McKayla 01:33 Yeah, me too. I’m following you for a long time now on on Twitter. And I was very impressed because you have a similar not the same, obviously very different. But you have a similar background, like coming from academia and then going independent. And and so yeah, so it was very interesting to see how you built Catharsis Consulting. And you’re the founder of Catharsis Consulting, right?

Dr. Cat Hicks 01:59 That’s correct.

Dr. McKayla 02:00 How did it help people with empirical research and also empirical research? I really a software engineering area, and you are now empirical researcher coming from experimental. How do you help companies?

Dr. Cat Hicks 02:14 That’s right. That’s right. So it’s delightful to connect. I think there are a growing cohort of us out there, you know, in the world who have made this journey, and there’s not really a roadmap for us. So I’m always I love to talk about it.

Dr. Cat Hicks 02:27 I like to call catharsis and evidence-science consultancy. So this means that we help partners use evidence to inform their decision making and tell their stories. And in particular, we’re very focused on meaningful measurement. So I describe it to people as not just data for the sake of data, but creating research methods that give us data that’s fit for purpose. So I try to help partners who are trying to learn something real about the world they’re working in, and how to move forward. And we have a couple

areas of competency and special focus. But we’ve led projects, it’s easier to give examples right, then talk high level. So some recent projects are, I’ve asked things like how can we find evidence that a product design change in a language learning game actually increased the learning that was happening for children using the game. Another recent project is using surveys to help a small nonprofit tell the stories of how community members that they worked with, were helping people in their own families and in their social networks, learn about the COVID vaccine and make the decision to try to get that vaccine. So both of those projects, very different scale for those projects, very different types of data. But both of those projects connected to really immediate impact, whether it was on product design, or on an intervention, and programming that help doctors have better communication with their patients. So at catharsis, you know, we try to bring a few core principles to all of our research projects. One of them is just that people deserve to understand their data, and to really use the data that they already have maybe special access to, and to try to bring the tools of empirical research to everyone, even small organizations that may not have invested in learning those skills before. So one thing that we bring in a lot of our partnerships is an emphasis on teaching those research methods and taking it not just from, you know, findings on one project right now, but actually fitting any work that you do with data into a larger plan of moving forward.

Dr. McKayla 04:39 Yeah, and it sounds really, really exciting. And it reminds me, I’m more on the training side, right. So I’m helping a lot of software engineers actually get better at code reviews, but all of that also based on empirical research that I did around code reviews, but recently this year, actually half of the year I spent on I’m a research project with this startup and help them come up with a framework on, you know, what makes developers developer experience really great. And they created a product out of that. So I can totally relate to that. And it was really a wonderful experience. But the experimental nature of research and startup somehow there was also a lot of tension, I would say, right, there was a lot of, you know, it’s very different than in an academic world, you have like these questions, and here was, every day, I want to squash the question, is this impactful? Is this impactful? Right? I don’t know if you experienced that as well. And how do you handle that in your work?

Dr. Cat Hicks 05:42 I think we all experience right, right, you know, there’s a tension between things that you’re doing for the long term and, and needs that are in the short term, and then, you know, just to be really real about it, I think there’s a lot of people who have agendas about what we’re going to find. And yeah. And I, you know, I try very hard to always work with partners who, who have told me, you know, we are going to make changes based on what we find, even if the changes are uncomfortable to us for even if it it, it helped, we learned something that conflicts what we thought was before, this is very important for social impact work, you know, is very important for equity, when you’re going to do anything that has to do with people’s well being, but it is a core tension. And I think that researchers, we tend to be people who love the truth, right? And we’re just all about finding out the truth. And that can ruffle feathers. I love to do exactly what you described, where you go from working closely with people who are living an experience, and then translate that, you know, to leaders and to organizational structures. And I think it’s a beautiful role to be in, but it requires a lot of invisible work, right of explaining both sides to each other.

Dr. McKayla 07:00 Yeah, and, and working with this tension, right, which I think, is tell for me, it was a very challenging time at a time that I learned a lot. Because I’m, you know, for me, the rigor of the methodology is the most important thing. Right? And, and then comes time for the sort of, it’s more the time and then the rigor I think, right? Like, yeah, obviously, you know, like, at least a little bit, there is the priority or they are more stressed by a timing, then you know, then a researcher probably, yeah, and so on. So you have to deal with these tensions. And I think it was a very, very interesting learning experience for me. But what I really love this, that I could see, this research transformed into a product. And this was, this was actually the reason also why I loved academia because I was missing that. Yeah, getting real, right, I created a lot of prototypes in my in my research career, and actually think some of them maybe would even have had some potential even for open source, right, maybe not making tons of money, but some open source software that people would have used. But it was never the time. Again, we are coming back to time, but in a different way. Right. So the time was up after the paper is published, the time was up to work on that. And so I felt like I couldn’t really translate it into what I would like to see. Right. And that’s why I left for example, academia. How is that for you? Why did you leave this traditional path of a researcher and and start your own company and do your own thing go independent? Right?

Dr. Cat Hicks 08:40 Yeah, for sure. So you know, I think that it’s interesting because I am a researcher who likes to study environments. So whenever you ask someone about their choice as an individual, I think you have to see it also as a choice about what was around them. So I’ll be uh, you know, I’ll be real about that. I mean, academia is very hard to succeed in, not, not because of the quality of your work, but because of the opportunities that are around. And I but I think that there was a really core piece of what I loved. So I started out working in classrooms, I started working, asking about the beginning of how we learn to learn and even in my academic work, I was very interested in being in real schools talking to real children was where I started I did a dissertation with 3 to 11 year olds, so you can imagine Oh, yeah, yeah, asking young children about their how they were thinking about mistakes and how they were thinking about learning. So from the very beginning, so cool, you know, it’s amazing how much it pays off, right? Because we all we all start there and even now I work with adults, you know, and, and yet, all of the same questions come up all the time. So, you know, I think getting I found it beautiful and amazing that people are constantly scanning around them asking whether it’s okay to make mistakes and asking who they can talk to. And I just, you know, I saw a lot of exciting stuff out there in in tech. I think the journey for me too, there’s a personal, you know, that’s kind of the problem space. But being an entrepreneur is also a way for me to carve out this role that I did not see existing. So I always felt a little bit like, I’m a social scientist and a data scientist. I’m a data scientist, who cares, you know, about how we measure things. I like meaningful data more than big data. You know, it felt like with catharsis, it was a way to make the job that I wanted to have, you know, to do these kinds of projects.

Dr. McKayla 10:47 Yeah, that’s exactly what I did as well. I love create the job that I would like to do that, then that I feel like I can strive it.

Dr. Cat Hicks 10:57

And it takes courage. Yeah, no, you have to have to say, I know this is valuable, which I think you do as a researcher, just like you were talking about that startup, sometimes you have to be the person who’s saying, I know that this will pay off if you will do it, you know, you haven’t measured it. So you can’t see it yet. But I know it will. Because I’ve been there working with people and I see their pain and frustration or whatever else. And then they build it into a product. Right. And it does pay off.

Dr. McKayla 11:23 Yeah, exactly. Right. Yeah. So I looked at your newest report, which was super interesting for me, because it is around the software engineering teams. And there you shed light on the learning debt that we have, and how that can affect engineering teams. Can you tell us a little bit more about what this report is about what this software? Or what is research actually investigated? Or looked at? And what is what is learning data? And why do we have it as software engineers?

Dr. Cat Hicks 11:56 Yeah, great question. So as a part of Catharsis’ work, I can occasionally invest in this sort of work basically, for the field. So this is a report I did, because I found it really interesting, and shared publicly, and it’s called coding in the dark. I interviewed 25 software engineers or developers, and I asked them to share about their active problem solving as they were ramping up on an unfamiliar codebase. So this was people talking about their real jobs right now. They shared about code review, they shared about how they asked for help, how they collaborated. And I’ve shared a lot about, you know, what we talked about. And essentially, you know, what I found was even at these really big tech companies, most of the people I was talking to, we’re all at big tech companies. Even at these places, people’s experiences were really quite frustrating. So I called this report coding in the dark, because that was a quote from one of the people I interviewed, describing how they felt every day, like they were showing up, and the lights were all off, you know, and that they were having to fumble their way through learning without any help from anybody. And there was this core tension that they experienced between feeling like it was so important to learn to build their understanding, to experiment, iterate, but then when they showed up, you know, to code review, and to other moments where they were being evaluated, that learning was not being valued. So I described this cycle, you know, of needing to do this work, and then finding it devalued. And going back to your kind of heads down at your desk, you know, I describe that as learning debt. And learning is essentially the dynamic that happens when people know they need to put a lot of effort into learning. And they know that the kind of work they need to do requires these mistakes. And it requires this long term understanding. And there’s kind of all of this stuff that you’re doing that’s sort of invisible, because it’s not showing up in your productivity. And they also know that the environment around them is only measuring that short term productivity. So in this kind of environment, where there’s a lot of learning, debt, accumulating, essentially, you know, learning you have to be do that you’re not getting rewarded for there’s also a lot of performance, pressure, and what’s worse, you know, things like documentation, writing code, comments, trying to help other people, you can actually feel actively punished for doing that. Another quote in the one of the interviews I led was that learning would be seen as a waste of time. And I think one of the engineers called documentation and code comments, a red flag about your abilities as an engineer. So you can imagine how that feels. You’re in an environment that’s telling you to do all this complex work, but also telling you that it’s a waste of time if you help anybody else. Learn from what you’ve learned. So, you know, a big conclusion that I have in this report is this debt cycle this learning debt cycle can accumulate

damage for a long time because teams might look very productive on the surface, but you’re building what’s really an inefficient experience for learning. So I’ll stop there and kind of Yes, more.

Dr. McKayla 15:09 So yeah. Tons of question for now, the first one is really what kind of persona did you interview? You were saying people that are new to a code base, but it is, are you? Did you ask them when they were onboarding? And is that the onboarding experience for people? Or is that somebody that’s already on a team, but within you problem, it sounds more like an onboarding, experience. And, and, and heavy onboarding experience. But

Dr. Cat Hicks 15:37 yeah, it was a mix, it was a mix. So I think that one thing that’s interesting is that you might think, Oh, this is somebody who’s just new to a whole company, you know, they’re experiencing the, but actually, I found this was a repeating cycle. So some people were fairly junior, you’ll see there’s a, there’s a cross section of seniority. So we really wanted it is a qualitative project. So it’s, it’s not intended to be a representative sample, I think, you know, follow up surveys on this kind of thing would be really, really fun to work on. But in this cross section, we did have a good number of junior folks, but also senior folks, even a couple people who are leading the engineering teams at their organization, I did ask them to bring in an exam, think about before the interviews, when they were a recent problem they had of basically trying to understand someone else’s code. So if this for some people, this was a really brand new codebase, right, like the whole thing as they were joining a company, but for some people, it was just a piece that they hadn’t really touched before. So yeah, it was happening really all over the place. Right? Yeah. So the

Dr. McKayla 16:48 other question that I had, when I tried to envision this is, what kind of learning because there are many things that are you know, that we can learn as software engineers, and I feel that everything that has to do with technology is rewarded, and is seen as something, you know, that that you get some credit for at least, and that it’s also very internally, a lot of engineers like to learn new technology. But then if you’re coming to code basis, the main knowledge, right, all the work that you have to do to understand this piece of code for code review, and so on, right? I can maybe relate more than this is the kind of learning where would see this, you’re, you’re supposed to already know it. Right? So let’s skip that step. You know it, and then you do your productive work? And why do you you know, this is somehow the invisible thing? Is that is that, you know, is my just guess, here? Is it going in the right direction? Or what kind of learning? Did you? Did you investigate here?

Dr. Cat Hicks 17:48 Absolutely. And I love that you have called out the complexity of learning. And you know, it’s learning is a big word for a lot of different things. Right. And, of course, you’ve had some really phenomenal thinkers who have broke out on this podcast that I’ve really enjoyed, who’ve talked about, you know, productivity is not one thing, satisfactions not one thing, the same could be said for learning. So, you know, I, I thought a useful contribution in this report would be to talk very broadly about the beliefs we have about learning. But the actual specific examples are a lot of different things. And I think it does map on right to, to exactly what you said. So developers feel like, Oh, if I’m learning a new language, or

a new piece of, you know, a new tool, something that’s very explicit, right, that’s easier to defend. And it’s easier to justify. But the focus is always on the technology, right? And the production and not so much on, oh, now I really understand how this other team has a mental model of, you know, this connection piece, or I really understand this dependency that happens. And I understand these trade offs.

Dr. Cat Hicks 18:55 So you know, there’s actually a tremendous amount of content I got in these interviews, that’s not even in the report, because it was so much. I think it could be another report on the kind of active learning that they were doing. And a lot of it felt, you know, almost secretive, like people were saying, oh, you know, I’m sure no one else has to do this. Like, I do have to go back and remind themselves, you know, because I don’t want to talk about it, because I’m afraid I won’t look like an engineer. But the reality was, to me a lot of that stuff, like thinking about the trade offs of different decisions you made thinking about whether a design decision, you know, that we put on paper really was that way in the code and even questions that are kind of like, is it worth the investment to fix this inefficient piece when I could instead be working on this other piece? You know, these are very abstract things for people to be thinking and learning about but they’re really, really critical. And I was reminded to, there’s a lot of myths around learning, right? And as a social scientist, I recognize some of these myths. So people will tend to think, once I learned something, it’s just learned forever, right? It just goes into like, my brain is a bucket, and I just dumped something in there. And it’s always gonna be there. But actually learning is really a behavior over time. So the mourn environment cannot see it as shameful, but see it as beautiful and productive and great that sometimes we’re asking each other for help. We’re reminding ourselves how things work, you know, and you see that when developers talk about googling for answers, right, and asked on Stack Overflow, and all of these other kinds of things that people do. But it was interesting to me how much they hid that stuff from their environment. Yeah,

Dr. McKayla 20:44 yeah. Because the real engineer knows all the keyboard shortcuts.And I think it’s so it’s so true, what you say, right? So learning what is learning? And if we are making a decision around trade offs, I think very often it’s not framed as learning. And then it’s also how, you know if I can write it down. And you know, if it’s not in a book, if it’s a very specific instance of something, another general thing that I can learn. What does this even mean? Right? So we learn, for example, about object orientation, and you know, how to how to have objects, but then to really think about this piece here. And the instance of should I create an object here? And how should the object look like and that I have to think about that is a little bit shameful, because, obviously, I learned object oriented programming. And so it should be easily coming to me, you know, what methods I should put in here, or naming, right? naming a method? Yeah, it’s also learning somehow, or we have to put the time into, and then it’s hard. And even though we make jokes about it, if somebody sits next to you, and you have to think about a good name, and only stupid names come to your mind. It’s horrible.

Dr. Cat Hicks 22:07 Yeah, and I think you’re, you’re, you’re pointing out something that’s actually really, really important here, which is, you know, there are good jokes and bad jokes, right. And we’ve, we’ve been around, we’ve all probably been around someone who has made a joke, you know, that has made us feel really

bad about how we learned or a mistake that we made. And this is something that came up in the report to that, you know, I think one of the quotes was, I’m always watching, like, I’m from a junior code writer, or someone said, I’m always watching the senior members of my team, because I want to know, what an engineer is supposed to sound like. And that can be really beneficial. If the people around you are saying things like, we all make mistakes, we all forget something, you know, we all help each other. That’s a good learning culture. But a negative learning culture, right? A bad culture is a place where people are, are saying, oh, you know, don’t waste your time, like doing this documentation. Like in order to get ahead, what you actually need to make sure you’re doing is putting on this performance. You know, things are very multifaceted, as you know, all of these things are always happening at once. But I do think that there’s in engineering culture, there’s a lot of myths around what brilliance looks like. And this is where I’ve pulled from some research from people like Andre Symbian, who’s done some work on, you know, when a field thinks that you don’t make mistakes, you have to just be born brilliant, then that is a story. That is not how it works, right. But we’re all kind of upholding that myth.

Dr. McKayla 23:41 Because we all want to be the 10x Engineer, right? And then we had to have 10x engineer. Oh, my God. Yeah. No, but something.

Dr. Cat Hicks 23:51 Yeah, something that, you know, just just hurts my heart, honestly, to is is like, the people who people do this work, right. People do mentor other people, they do support learning. And that actually is what creates 10x results. It I mean, investing in learning is one of the most evidence backed ways that we have to you need to do work together. And I had, if we could see it as something that we are sharing, and that we’re all working on outside of ourselves, you know, it’s it’s never about, you write bad code, I write bad code. All right, fine. Like we work to make the code better. It’s outside of us. And it does not tell me who you are as an engineer. In fact, a good engineer is someone who’s written a lot. Yeah, I mean, we need to, you know, we need to improve things and give feedback, right. But I think we need to value the messages that that feedback sends.

Dr. McKayla 24:47 Yeah, I think that I want to come back to this different kinds of things that we learn and, you know, writing good code, whatever that means. And it’s also I think, changing over time. What is good code, right, whatever, what is a good way to write code but a good applications, how to structure them that also evolves? But again, I would say this is this textbook knowledge, right? And then I think what’s, and this comes back to code reviews and to the data day to day work that we have to do and to productivity a lot as well, is this constant learning? Right? I cannot stop learning. I cannot, you know, it’s not like, Oh, now I work. You know, obviously, you get better at this code base, and more familiar with the terminology and with your, how your team works, and so on. Yes, right. But still, even if I’m at this team for three years, and have worked with this code base for X years, right? If I have a new change that somebody else wrote, then I have to look at this code. Yeah, starts right there. And you know, and I cannot come in and have this full bucket of knowledge of how that works. And then, you know, supposed to already point out what was going wrong here. And maybe it has to do with how we measure time, and then a lot of people I think, have really problems with time, I have a lot of problems with time, like, when when should I leave the house to be on time, right? And I think very similar, we

estimate, for example, how long will it take to make to look at this code and give comments. And very often people reduce that to the time to make the comments, but this learning part that is never stopping continues and will have been added nobody wants to talk about and you know, nobody actually wants to have and nobody has time for it. That’s that somehow gets forgotten or is forgotten. Right? Yeah. Oh, I

Dr. Cat Hicks 26:42 agree. I agree. And I time came up a lot in these interviews. And it doesn’t surprise me because, you know, we all have felt this time pressure. And what I kept asking was, you know, if you’re experiencing this time, pressure, like, what is the the first thing that gets cut? is, honestly, to me some of the most valuable stuff, and that is really hard for people. So, you know, there is a sense in which I think I totally agree that doing this work, the learning will never stop. And you’ll you know, it can feel a little overwhelming. But I think that that’s a reason to say, you know, what success is not you getting to the end of your learning. Like that’s not what success is success is having enough space to make a good decision instead of a bad decision about how we move forward. And I, I did see people go through that. And actually, you know, I agree that it’s very difficult sometimes with this work to predict how much time it’s going to take. And I experienced that with my own work. People ask you to do a research project. And you say, okay, like, it sounds, it all sounds good. But I need to get in there and see what the truth is. And we might learn, it’s way more complicated. So I think about things like, you know, can we have measurements of productivity, that is dynamic, that we’re able to come back to and change it, and I think people will get get very, very frustrated, you know, when they are assigned a project, they dive into it, they do all this learning, actually mapping out how complicated it is, is a very valuable piece of learning that they’ve done, and they turn around and they want to share that with somebody, and there’s no way to share that, you know, there’s no way to kind of get credit for it. So that’s, you know, that’s one thing I think about is if we can make some of that more visible, right, like, like, allow you to use the learning and share it with collaborators, I think that people really enjoy that they feel the productivity of it, even if your goals of the project change. Another thing is, you know, can we talk about where time pressure makes sense? And where it doesn’t make sense, right? So can we prioritize and and see the cost of putting everyone under a time crunch all the time? And where that is just creating these learning cycles? Yeah. So

Dr. McKayla 29:06 what I want to understand a little bit more is, there were definitely some outcomes from this report, tell us how prove right? How can we reduce these learning that how can we have this growth mindset? How can we, you know, how can we in our at least in our engineering team, a celebrate learning and make it a bigger priority? What are some of those outcomes? What can you suggest engineering teams that want to improve their learning experience? And, and the valuing of that?

Dr. Cat Hicks 29:40 I think there’s a piece of this puzzle for every different role, right? So, you know, from leaders, from engineering leaders, these people could have a really outsized impact on the culture and I think that you know, a lot of places will put a poster on the wall that says everyone could learn or or maybe there’s a bullet point in a slideshow about like we’re alerting culture. But if you go to work and you see someone actually get rewarded for a complicated learning situation like, hey, you know, we gave, we

told you to go try to do this thing in the codebase, it turned out the thing we, you know, the thing that we proposed was not possible to do. But you did all this learning, you figured out a better way forward, we’re gonna celebrate that instead of, you know, coming down on somebody for it being not what we expected, those kinds of moments. And I think leaders have the ability, you know, to, to notice that to try to push themselves to amplify that that can have an impact. Another thing I would suggest, you know, that I suggest in the report is, we honestly need to separate some of our development feedback from some of our performance feedback. So okay, I don’t know how many conversations you’ve had with engineering friends, about perf cycles. But perf cycles are a huge source of stress. And even though we have invested, this is a whole area of research this ton of people, you know, who look at this, but even though we have invested huge structures into it in tech companies, a thing that I keep seeing as a learning scientist, is that we are rarely letting people have psychological safety to talk about them learning. So I think that a very simple step that leaders could take, is to make space to separate when you’re talking about how you want to learn and grow and develop and maybe explore areas of growth for you. And separate that from promotion, performance, reputation management times that you are trying to defend yourself, which is very difficult, you know, you can’t really do those two things. At the same time. I have a number of other recommendations in the report, you know, I think that there are some simple steps like, have we put any time in our calendar for documentation? Or are we just acting like that’s gonna happen magically by itself? You know, so there are small and big steps to try to make yourself a learning culture. Does that all make sense?

Dr. McKayla 32:05 Yeah, totally. And I think documentation again, is, maybe it’s the last thing that I want to talk a little bit about. Because I think there again, we have these two different kind of learnings of information of sharing. So you have this external documentation of how things work, right? And, and people agreed, and you know, in API needs documentation, but then the nitty gritty part becomes a little bit translucent, right? It’s like, oh, this method, actually, you should be able to understand it just by looking at the code. Otherwise, the code is not good. And don’t put a comment there. That’s really bad. Right? And I, I, sometimes I, I really can’t understand the problem here. Because while it’s great, if you know, and there are different learning types, and you know, in different people that maybe somebody is easier, you know, it’s easier for them to look at the code and really get it then skip the skip the comment, right? And some people like the comment, and it gives them context. And you can really know in, in, you know, native in your native language or in in, you know, in written language instead of code. But again, here, there comes this the myth a little bit as well, right? We say, well, code shouldn’t actually be documented. And you shouldn’t need documentation to read this. And there is also some research around that. And they showed that if there are comments in the code, people are slower with reading the code. But why? Because they are reading the comments. Right? And would they read the comments if the comments are useless? No, they are reading the comments, because they’re actually helpful. Right? And

Dr. Cat Hicks 33:45 that’s such a good example. Yeah, that’s such a good example of a measure that like is taken to be a negative measure. But why it might actually be a positive measure? Yeah. Yeah, I think it’s, you know, you bring so much rich lived experience on this, and I love hearing it because it’s, the reality is that these are going to be contextual decisions, like a code that was as you said, code that was good,

quote, code, quote, unquote, in one time, my deal if the context has changed, and then that then, you know, you need to make a different decision. And I think that there’s, there’s there were these interesting quotes, you know, when I interviewed people about who, who is this for? Is the documentation actually, for me? Or is it for, you know, like, some idealized scenario where we’re describing the technology and point of view that I have in my consulting, you know, is that I like to focus on people as the heart, you know, and that code writers as learners, like if we, if we take this approach, where we center they’re learning, we can be a lot less afraid of things like sometimes the trade off is that you have more comments and that that doesn’t work for all situations, but you have preferred did some really deep losses in efficiency and invisible losses that are happening? So if someone’s able to ramp up a lot more quickly, that’s a huge game. And I think something difficult about it is that sometimes that gain is really invisible. But you know, it’s, it’s not really possible to have a single way of describing code that’s going to work for everyone who’s ever learning. Yeah. And similar to measuring developer productivity, I think it’s, it’s a question of what is the best thing for us right now. And what’s going to pay off the most, even if it slows us down a little bit in this way, then I think it will really pay off. If you know, later, this person who we gave all the support to is able to become this champion contributor. And I just think, you know, I use the learning debt cycle, like the learning debt metaphor to, to evoke tech debt, because we understand tech debt right in this field. And we understand that technologies with all these dependencies can start to break apart, even if it made sense when we built it. And I think the same is true for collaboration. Yeah,

Dr. McKayla 36:11 Yeah. Yeah, there’s so much goodness in that. And I really want to dig into the productivity. So maybe what I want to do is I’m going to invite your again, a whole episode just on productivity if you’re up for it. Yeah. And then we can really dissect that, because I would love to hear your, your opinion also on, you know, you mentioned or hinted a little bit towards that. Can we measure learning as part of our productivity? Right. And I had a podcast where was just me talking about productivity. And there, I was asking the question, I was saying that all these productivity measure that we have focused around activity, right, coming from an area of the industrial age, right, where, well, it was the activity that better Yeah, exactly. And it was that the activity that we did, right, you had only to do very mechanical tasks, and the small task, and so you could count them, and so on. And all those measurements actually stem from there. And now we put them on knowledge workers, were probably the most productive thing is that I’m sitting here doing nothing, but I make a really good trade off this session. Right? That’s right,

Dr. Cat Hicks 37:21 that’s right, or you help someone else and they do something, I would love to have that conversation. And I do think there are ways we can measure learning. And you know, if anyone is going to be listening to this, like, go to your team right now and ask, what are the things that we do that really make a difference, that are not being captured anywhere that are not being rewarded? Like what is the stuff that you know, is important to do to keep this all of this running? And they will tell you?

Dr. McKayla 37:53 Yeah, yeah. And coming back to what you say, with the sharing, I think what I have seen work really well is small things like brown bags, right? Where we come together, and somebody just explains what they have learned this week. Or if you go back to code reviews, right, that you that every Friday, for

example, that’s happening on GitHub every Friday, they are sharing, and sometimes they are sharing, what did I learn this code review? That was really excellent. Right? You know, it’s a comment that, uh, no person really took the time and gave me great comment. Or I’m showing some code that I have seen that I haven’t seen before, or, you know, some some Yeah, paradigm or something that I’ve seen. So and we are sharing, we’re making some of those very implicit things that are internal that are not, we are making them explicit and sharing them. And I think this is a celebration, as you said, I think those are themes can maybe do to celebrate what’s also often referred to as blue work, right? Oh, this, this colleague helped me or that person, you know, they didn’t work on their ticket, which had them for their promotion, but they actually went out of their way and did this and that, right. And so, we open openly sharing this and making it explicit. And I think, especially in our remote world now is more important, right, that we have shared that somehow. Yeah, no, I

Dr. Cat Hicks 39:16 think that that’s a beautiful point. And really, really important. And, and something that I also thought, you know, something again, that people people said in the interviews, which was, I want to see specific examples. I want to sit next to somebody and see them, see them code, you know, and, and that just I think people don’t know how much that doesn’t happen. I think they assume it’s happening or they say, oh, go get coffee, you know, with this person who wrote the code, you’ll, you know, go talk to them. But people often struggle, especially if you’re remote, you know, if you’re new person, there’s all kinds of ways in which people you know, reasons that people might not ask for help. And as I told you, I started out my career looking at Three and five year olds and in classrooms and when they ask for help, and even when we are four and five years old, we’re looking at the people around us. And we’re asking, Can I Can I ask for help? Can I talk to you about my real learning? So that continues? And the more you see those small messages, and those small social moments can just have a huge impact.

Dr. McKayla 40:23 Yeah, yeah. And I think team culture and psychological safety, and all of that is so important. And it’s, it’s, it’s not something that you can just fix by doing three things today, right? It’s something that you can start. But it’s a continuous process. And I think this is one of those very rewarding things and you know, things that pay off, but are a little bit invisible, that you have to constantly work on that right, and that you have to raise the bar and say, we are actually allowed to have questions be wrong, you know, growth mindset, and I think it’s really, it’s a continuous work in a team, but the teams that managed to do it, they are so much better off than That’s right.

Dr. Cat Hicks 41:07 And it just is a beautiful part of it, you know, I try to make these problems easier for myself, and for other people by saying, who’s already doing this, right? Like, how do we give them a stage to do it? Like, you’re who’s the person that someone always everybody goes to this person to ask for help? You know, how do we make sure that they are instead of being like, burdened by this invisible work, they’re actually rewarded for all this support that they’re doing? Yeah.

Dr. McKayla 41:34 Yeah, that’s so true. Well, it kinda, it actually brings us to the end of this show. I said, I’m going to bring you back. If you have time. I will continue. We can continue this discussion a little bit more. But is there

anything that you want to tell my listeners, maybe that you think, you know, wraps up some of the learnings that would be powerful for them for the software engineering teams? How can they, you know, be in a better place? What are what is the one advice, you know, that you would give them?

Dr. Cat Hicks 42:08 Yeah, great question. How, what a lovely question to be asked, you know, I think I end the report that I recently released, saying, learning matters. And I would I would like to leave with that, which is that, you know, learning matters and measurement matters. Like whenever we measure something, I think, Who is this measurement for? And is it bringing us closer to this culture that we want to have, you know, where we feel free and happy and, and like, we’re all learning together, which is what we need in order to tackle these huge, complicated problems in the world, you know, we need to get past some of these myths about where brilliance comes from, and the myths that we all need to hide, you know, are learning from each other. But that people will only be able to do that if we make the environment around them safe. You know, so it kind of comes from both sides from from us building the environment as individuals in it, but also from people who are able to kind of say, well, I’m gonna, I’m going to do something to make this environment safer. So that’s what I would say, you know, learning matters, it pays off. Let’s let’s work for it.

Dr. McKayla 43:18 Yeah, that’s beautiful. That’s really great. So thank you so much cat for being on my show. And I will definitely ping you again and ask you for more of your input. Thank you so much. Okay. Bye bye.

Dr. McKayla 43:35 This was another episode of the Software Engineering Unlocked podcast. If you enjoyed the episode, please help me spread the word about the podcast, send episode to a friend via email, Twitter, LinkedIn, Bell, whatever messaging system you use, or give it a positive review on your favorite podcasting platforms such as Spotify or iTunes. This would mean really a lot to me. So thank you for listening. Don’t forget to subscribe and I will talk to you in two weeks. Bye.

 

Running a developer community

In this episode, I talk to Bekah Weigel, who runs the virtual coffee community about community building. 

Bekah graduated from a Bootcamp in 2019 and quickly created a striving and very special developer community in just under two years. 

We talk about:

  • how she kick-started the developer community virtual coffee
  • what it takes to run the community
  • how sponsorships make it possible to be sustainable, and
  • how community members take over a large part of running the community. 
Bekah Weigel

Today’s episode is sponsored by Codiga, a smart coding assistant and automated code review platform. Try Codiga for FREE!

Subscribe on iTunes, Spotify, Google, Deezer, or via RSS.

Transcript: Kickstarting and running a developer community

[If you want, you can help make the transcript better, and improve the podcast’s accessibility via Github. I’m happy to lend a hand to help you get started with pull requests, and open source work.]

[00:00:00] Michaela: Hello, and welcome to the software engineering unlocked podcast. I’m your host, Dr. Michaela. And today I have the pleasure to talk to Bekah Hawrot Weigel, a web developer and creator of the virtual coffee developer community.

But before I start, let me tell you about an amazing startup that is sponsoring today’s episode: Codiga.

Codiga is a code analysis platform that automates the boring part of code reviews and lets you merge with confidence on GitHub, GitLab and Bitbucket. I’ve worked with Codiga for around one year now and I really love how it guides me in discovering and improving, well, the not so nice parts of my codebase.

But there is more. Codiga has a coding assistant that helps you write better code faster. Find and share safe and reusable blocks of code within your favorite IDE on demand while you’re coding. Codiga has a great free plan, so there’s nothing that stops you from giving it a try today. Learn more at Codiga.io. That is Codiga.io.

But now back to Bekah. Bekah graduated from the bootcamp Flatiron school in May, 2019. And since then she started a consultancy specializing in front end development and created the developer community virtual coffee. She also recently started her new job as a technical community builder at deep gram.

She’s also a mom of four, so I’m totally impressed. And yesterday I went to pick her brain on how she could develop this awesome. Develop a community so fast in just a little bit under two years.

So that come to my show background, I’m really, really excited that

[00:01:41] Bekah: you are here. Thanks so much for having me. I’m very excited to be here. Yeah.

[00:01:45] Michaela: So can you tell me a little bit about virtual coffee, what it is? And for me it seems a little bit different than other communities. It seems a little bit, a little bit more niche, grit, like closer.

W how would you describe

[00:01:57] Bekah: it? Yeah, I think that’s a great way to [00:02:00] describe it. We always like to say that we like the intimacy of virtual coffee because we’re a small community of developers where all stages of the journey. So if you’re just learning, if you’ve been doing it your whole career we’ve got everybody and we’re tech agnostic, so it doesn’t matter what, what tech tools you’re using.

If you want to meet up with other developers and share and support each other. We’re here for it. So we meet up twice a week when we meet up on Tuesdays at 9:00 AM, Eastern and Wednesdays at 12:00 PM Eastern for some chats. So we go into breakout rooms. So we have small group conversation. We like to maintain that intimacy.

And then for members, so people who have attended at least one virtual coffee, they’re welcome into our slack and our members only. So we have lunch and learns on most Fridays, we’re running our third round of lightening talks soon. We’ve got monthly challenges and some other small groups that meet that are building within the slack community, which is just so great to see everybody supporting each other and working to meet the needs of the community.

[00:03:04] Michaela: Yeah. So there’s a bunch of things that you just mentioned. Right? So a virtual coffee. When I came to know it, it was mainly there’s. The weekly, or I don’t know if it was even PVT at the start, but it was like this virtual coffees where you. We’re seeing each other and chatting to each other and now it grew into something really big.

Right. And so you say you it’s, it’s a small community, but, but how large is it? Like how many people are participating here and, you know, , what else do you do to keep this , intimacy, Ronaldo and Messi. Yeah, exactly. Yeah. How do you, how.

[00:03:43] Bekah: , Well, you know, we’ve got our slack has almost 600 people in it, but I would like to just note that I think that, you know, there’s a lot of people who used to be active that aren’t active anymore.

And one of the things about the community is we’re really close, but it is transient in nature [00:04:00] because sometimes people are looking for their first job and they get it and they can’t come around much anymore. Sometimes people change jobs and their availability changes.

So, you know, one of the things that we really like is being able to celebrate wins with other people.

It’s bittersweet a lot of times because you know that they won’t be around much anymore, but you know, like occasionally I’ll get messages from people who came at the very beginning and it’s just so great to, you know, still have that connection and know that, you know, we support each other, whether we’re in slack or not.

So I would say maybe we have about 200, 200 or 300 active members, which I think is still pretty good. 30 to 50% of our slack is fairly active. And I think, you know, We maintain that intimacy by doing, by focusing on small group conversation and a lot of ways. So the small group conversation that happens when we meet up on zoom twice a week we try and keep our breakout rooms between eight and 14 people, but we have.

Start in the big zoom room together. And we go over some announcements, like our code of conduct and what the mission of virtual coffee is a little bit of our history just to allow people to get a glimpse of this is how long we’ve been doing things. And this is how, how things have grown. And so. By having that interaction with other people by seeing faces or hearing voices or interacting and a synchronous way, it provides some kind of connection and friendship that doesn’t happen as easily in async only environments.

And then it’s great to see what the community members are doing. We have let’s see here, we’ve got all of these small groups meeting within the community and. Tech interview study group. These are all led by members that happened on Monday. We have an indie hackers meetup on Wednesday, a react meetup on Wednesday and [00:06:00] a monthly challenge check-in on Friday.

So, you know, the members are really there to support each other and to see what the needs are. And so not, everybody’s going to come to indie hackers. I like to go to that one. It’s one of my favorites. You know, maybe there’s like. To eight people there, but it’s great because you can really dive into those deeper conversations and get to know people in the, those small moments in ways that you can’t when you’re in a large group of people.

So I think that’s one of the things that, that we’ve done well is have people who care about each other and, and see them supporting each other in their new.

[00:06:39] Michaela: Yeah, that sounds really good. And there are a couple of things that I want to touch base on that you mentioned, first of all. So I can imagine that there are like a hundred people joining your soup, and then you have this announcement.

Remember you’re members of what is all about, which I think is really good for the mission also, and for new members to, you know, Just introduce them to your culture code of conduct and them so on, but then how do you announce the different breakout rooms? Do you know, do people speak up and say, oh, I want to do a breakout room.

Is it like, I don’t know if this is an a term in English by the bar camp where you, and non-conference where it just self-organize itself or do you have to announce it beforehand? Did you know already, these are the topics of, you know, today’s

[00:07:24] Bekah: Yeah. So that’s a really great question. So we also, I should have mentioned this before, because I think one of the ways that we also have been able to support everybody is we have documented most of our processes thoroughly.

And that allows us to bring new volunteers on and to support new people. We think of pretty much every interaction as a opportunity for onboarding new members and to constantly remind people of the things that matter to us, which is, you know, being kind and recognizing that the impact of our words matters.

And so we have all of that created and we [00:08:00] have let’s see maybe about 30 room leaders in note takers. And so we have a process on Mondays where we see who’s up for volunteering to be a room leader or note taker. And we pick a introduction question, just a random question. It can be something silly.

Like what kind of dinosaur would you be? And so everybody in the breakout rooms answers a couple of questions, including that. And we have a Backpocket topic, but we always say that we like to prioritize what folks who are in the room want to talk about. So if they have a question or if they have a topic they want to talk about, we start with that.

And then if not, we’ve got that back pocket topic. We had virtual coffee today and our back pocket topic. I’ll read it to you. Just so you have a sample of some of the things, actually, all of them I think are listed on our discussions in our repository. Our topic today was what are some transferable skills you bring to tech either from a previous career or from other parts of your life.

And so actually my breakout room did talk about that. And so everyone there’s okay. So we have the. MC he’ll gives all of the announcements. And then we have a host who controls zoom and the host puts everybody into breakout rooms. So we already know who our room leaders and note takers are. Those have already been set up the day before.

And so we make sure that they all get in room and we try and have backup ones. So, you know, if we need a fifth room, then we’re going to have this person as a backup room leader. Which today I think we did end up using our backup And then the host goes through and fills all of those rooms and we do our best.

It gets chaotic when people come in late or at the end or drop off and come back in. But we do our best to make sure that we get a pretty well-rounded room. So new folks, people who have been there for a while, you know that some people maybe are leading for the first time. And so you want to put some.

[00:10:00] Dependable talkers and their room. And so you try and make sure that you do that, but that’s kind of the process for what we do and how we do it. Wow,

[00:10:07] Michaela: that sounds like you’re having a conference and the organizational, like I say, not a burden, but burden ID. It doesn’t seem like it’s a burden to you to organizational fun.

Every week, twice sounds like a lot of work.

[00:10:22] Bekah: Now that we have the process down, it makes it a lot easier. And we’ve got some, you know, Slackbots reminding us about some of the things that we have to do and where to look for things. And it, it is a lot of fun. There is definitely work behind the scenes that happens to make sure that we have a, a safe and welcoming environment for everyone.

But, you know, it’s worth it. If people feel like this is a safe space that they can grow. Yeah, definitely.

[00:10:46] Michaela: And I can really see like with this organization, I mean probably if, if, you know, like if you started there like five people come in, you know, showing up, you don’t need a lot of organization. Right.

But then if 10 people, and then it’s 20, then you know, you started developing those processes and you probably see also what works and what does not work. And what are some of the things that you tried that didn’t work out. So.

[00:11:08] Bekah: Well, I will say that when I first started virtual coffee, I didn’t even know that zoom had breakout rooms.

So that was a totally new concept to me. And I feel like I’ve got some expertise in it. Initially. I so virtual coffee started. I had been working as a developer for about eight months when the pandemic hit. And then I lost my job because of the pandemic. My kids were sent home from school. That same day.

They never went back to school that year. I think. And so I was really interviewing for the first time for jobs and I just didn’t have a great sense of the developer community out there, what the expectations were, how to make it through the interview process. And so I asked, you know, Hey, does anybody want to meet up for virtual coffee on Twitter?

And, and that’s why we’re so called virtual coffee. And so I’ve learned so much. And [00:12:00] initially I was kind of resistant to having a slack because, oh, I don’t know if we need it. You know, this is just going to be something we do for a couple of months. So I, I would say that maybe some of the things that didn’t work were, you know, pushing some of those things off for a while or being resistant to.

Adding we, we lean on project boards and get hub issues a lot in our organization. We want to make sure that we use tools where our members lived. And so I initially I was resistant. I was like, I can not look at one more repository no more. And now I’m like, yes. Yeah, we need a repository for that.

So. I think that my, my, the thing that didn’t work was my frame of mind around it, because for a long time, I thought this was going to be a temporary thing. And when we did our first heck Tober Fest event two years ago, that’s when I finally thought, oh, this is, we’re not going anywhere. We’re w this is not just a pandemic thing.

Like we’re filling a need for a lot of people, even outside of the pandemic. And so that’s kind of where. Things started shifting in my mind, like, what is the, what are the long-term processes and how can we make this sustainable?

[00:13:12] Michaela: Yeah. And it’s really nice. Yeah. I’m also like, I, I’m often thinking of creating a community around se unlocked, for example, the podcast.

Right. But I’m not sure about how it will, you know, what are the right tools? What is the right kind of community. I’m also more a person of like, I’m not really good at. Participant in the slack channels and this core channel, I get very easily overwhelmed. And then, you know, like maybe a week I’m trying really hard, but

If it already starts with that, you know, I don’t, you know, I don’t think that I can run a community like this, but having, you know, chats or, you know, soon conversations. I was also thinking about Twitter spaces. Is that something that came to your mind that you could maybe do as well?

[00:13:57] Bekah: Yeah. So I [00:14:00] went through, I ran a lot of Twitter spaces myself.

I went through a string of them. I was doing them weekly, and then I started live streaming, I think instead just trying to get a feel for everything that’s out there. But I think with my job at deep gram, we’re going to start doing some Twitter spaces that I’m really excited about because of the support of the team.

And we can do some really great stuff. Start build community and fill some of the needs that we see out there in the tech community right now.

[00:14:31] Michaela: Yeah. Yeah. And do you think that there’s a difference between a zoom? It assumed seems a little bit more intimate for me because you know, it’s, it’s a community that’s not completely public it’s public, right.

Because people can just respond and be part of it, but to the spaces for me, just because it’s there on Twitter and then you see at least some of the bubbles and then it’s broadcasted through other, you know, sort of followers of the people that are in there. And so on. People can drop in and go out.

Do you think it’s different and, and has a different need or fills a different need, a different purpose for the condition?

[00:15:07] Bekah: I think, you know, there are expectations when you meet with other people in a small group setting, face-to-face, you know, you, and we say like, if you want to leave your camera off, if you want to stay muted, that’s totally fine.

If you want to throw things in the chat, that’s a great way to communicate as well. But still you see other people there, whereas Twitter spaces, you can kind of come in and out. You, there’s not the sense of, oh, I have a roll hill here that I have. Bill because you’re not a speaker. You can be a listener.

And so in. Twitter spaces I think is closer to watching a live stream because you can interact through the chat, but it’s a little bit more personal because if someone’s live streaming at Twitch on Twitch, you don’t see everybody who is there, but in Twitter spaces, you can see those other people and they do connect you.

Other like, you know, if we follow [00:16:00] each other, I can see whose space you’re in. I’m like, oh, okay, well, she’s there and she’s cool. So I’m going to go check out, you know, what she’s listening to. And so there’s a, I think a little bit, maybe more community happening in Twitter spaces, but there’s less like barrier to entry or friction if you’re shy or an introvert or, you know, just kind of want to check something out one time.

so

[00:16:24] Michaela: another thing that I wanted to talk with you, and I think they are a little bit connected. One is that, so I looked on your website, virtual coffee.io, and there are a couple of people publicly listed. Right. And apparently they are not all of them. Not everybody wants to be listed there or it doesn’t, it doesn’t.

Hasn’t edited themselves. But a couple of people are really listed there. And then I also saw that there are different roles, right? You were also talking about the different roles for the meetings, but there were two particular ones that were like labeled there. And one was the, the. Maintainer and the other was the community maintainer.

So what are those two roles? Is that all the roles that you have and how do you select people or how are people selecting themselves to be in those

[00:17:07] Bekah: roles? Yeah, that’s a really great question and it’s kind of evolved over time. We’ve had so many people step up and offer support and offer help. And Sarah, McCombs, they were really great support at the beginning of.

Virtual coffee and, and making sure that we got this stuff done and helping build out these processes. And when we launched our first hack Tober Fest, we had a whole team that was focused on that. And a number of the people who were on that team ended up coming on as maintainers and. I’m both a, a core maintainer and a community maintainer and, or a, an org maintainer rather.

And what that means is we kind of look at the overall organization, the health, the strategy where should we go from here? What decisions need to be made in terms of the entire organization? I would say the community maintainers are [00:18:00] looking more at the day-to-day, the community management project planning that, that kind of more day-to-day focus, I guess, in, in making sure that the team is supported there.

So we all work together as a core team and we make decisions together and there’s always going to be overlap in all of those things. But it’s funny that you ask about these roles because I was just working on this. Actually we have some team leads and they should be going up on the site there.

They’re already listed there, but. You know, we have leads for our monthly challenges as Areli, Varo, and Andrew Bush for our audio visual stuff. So getting things put up on YouTube, helping with live streams, that’s bogged in. For documentation, we just onboarded a new team lead named . Who’s absolutely great.

I met with her this morning to kind of like walk through the process of, you know, how do we prioritize, what needs documented, where do we put these things? And she’s so great about, you know, asking questions and getting issues up on the site before I even think about them. So I hope I didn’t miss anybody.

I know that, that we work with. A number of other people as well to support the organization. But I think that, that those will go up on the site soon. We want to also have like a community health team lead and we’re talking to someone about doing that. Job search is a big thing at virtual coffee.

It doesn’t matter what stage you are. Somebody is always looking for a job. And so we have some great folks who do a lot of work on that. And so, you know, that might be up on there soon too. So, you know, we’re, we’re, I think we’re in the phase where we’re trying to figure out how do we best support our members and help provide those leadership opportunities that we want.

[00:19:56] Michaela: Yeah. Yeah. So when you describe all [00:20:00] of that, it seems to me this is a full-time full-time job already, but so how much, how much time does really go into that? I mean, there’s the meetings themselves, right? That you’re a participating and I’m even, I’m not part of virtual coffee because I don’t have the time to do it as.

Just as a participant. So I can imagine you have to be at the meetings, you have to plan the meetings and there’s the chat and you’re making all this. You have all these thoughts and meetings also with other members of the community, how to grow the community, how to, you know, keep it alive and make it healthy.

So how much time off your week goes into data? I can imagine

[00:20:39] Bekah: a lot. I don’t know. That’s a good question. At some point, I think. Stopped keeping track of how much time was going into it because it was a lot and it’s not a job, right. It’s a volunteer position. But I think, you know, now we have so many supportive members and with the core team that I’m able to do, where like we’re all able to do a lot more and to lean on each other.

And to grow in that way. And a lot of the stuff is almost like muscle memory. Now, you know, I’ve been doing it for so long that it doesn’t feel like it’s one more thing to do. There are always things that, you know, I have a whole board of things I would love to do for virtual coffee and I have to try and pace myself because sometimes I go for it anyway, and then I.

Well into something and I’m like, oh, I, I might, I might die after that. So I try to avoid that feeling now.

[00:21:38] Michaela: Yeah, I can imagine. So I have seen on the GitHub page, there are some, there’s some sponsoring going on, right? Is there, are there other ways that you’re monetizing this community or that the community monetize it itself, that it has some budget around that you can also do cool stuff.

[00:21:55] Bekah: So right now, sponsorships, we launched [00:22:00] sponsorships maybe in September. And so up to that point, we were just paying out of pocket for everything. But sponsorships is the primary way that we cover our costs. We had a monthly challenge sponsorship, which was nice. We have the podcast there’s opportunities for sponsorship there.

Oh, oh, we just launched a store, so, oh yeah. Cool. That’s really exciting. It’s just really exciting to see people like wearing the virtual coffee and sharing their stickers. So those are some ways that we’re, we’re working on covering, covering the cost of what we want to do, and then, you know, hopefully providing new services and.

Yeah. Yeah.

[00:22:38] Michaela: I think at one point you have to think about it because even like this lag is probably not free, right. You have to pay per month membered and.

[00:22:46] Bekah: Nope. So we’re on the free version of slack because it costs, I think $6 per member per month. Yeah. I saw there’s no way that we could cover that.

That’s so

[00:22:59] Michaela: crazy. Yeah. Yeah. Okay. So there’s a free version of that as well, because I looked into that, I thought like maybe, you know, slack channel and it’s not like $6. Why am I God, not.

[00:23:11] Bekah: Right, right. Discord, discord, we’ve gone back and forth about it. It has a lot of great tools. We’re just not in love with the user experience of discord.

But you know, we have class. So one of the things that we have Put a lot of money into zoom because we have accounts for our core team, but also we have a coworking room that stays open all the time. So folks can join in slack and the coworking room is always open. So that’s its own account. We, you know, producing a podcast can be costly you know, producing.

Transcripts and providing the services for that. We’ve got like Zapier and air table. So, you know, like we’re, we’re using all of these tools that we can to you know, make things a little bit easier for us, but do cost money. And so what we, we try and keep our costs minimal, [00:24:00] but you know, there, there are some, but I think that.

Covered right now for our CA our monthly costs by our sponsorships, which is really, really great. Yeah. That’s

[00:24:10] Michaela: really good. Yeah, that’s really cool. So what would you say to the listeners today that would like to, you know, start their own community, have a community? What would be the MVP, a MVP version of a community that you, you know, from your experience would.

Suggest to them, should they start with fitness spaces or should they have like a meeting or a slack or a discord channel, you know, what are the options and what are the pros and cons for each

[00:24:38] Bekah: one of those? That’s really a great question. I think that, first of all, I feel strongly that. You, there are a lot of really great communities already out there, and a lot of them really need support.

So if you are not all on board and starting your own community, explore some of those and see how you can help because, you know, you might be able to be on a core team or something that allows you the experience that you want from that. So I’m not convinced that every, every person needs to start their own community.

But I would say that I think trying to fill a need within the community is a really great way to start one, because if you see that there’s a gap or that people are asking for things, or, you know, like one of the things we’ve been doing virtual coffee for almost two years now, and we get the same questions in our Our zoom sessions.

All the time. And so I can tell that there’s a real need for more work, to be done around interviewing about supporting junior developers about creating positive workspaces. So for sure there are. For groups that focus on those things. And then I would say for me, if you start a slack or a discord, that’s probably the most time-consuming [00:26:00] thing that you can do because you want to keep people engaged.

You want to keep them talking, you need to answer questions. So if you don’t have a core group of people, Then it’s going to be really, it’s going to be a lot of work to try and keep up with that. I also think that we’re in the pandemic now and people have been collecting slacks and discords, and when things in the pandemic start to ease up, we’ll see that a lot of those communities, I think, start to fade off just because, you know, people are going to prioritize the couple that they’ll keep and stay active with.

And, and then they’re going to be, you know, doing. In really stuff.

[00:26:42] Michaela: Yeah. Yeah. Which is good. I’m I’m waiting for that.

[00:26:47] Bekah: Yeah. Yeah. So I mean, thinking about like, okay, maybe you want to then create some kind of hybrid model or, you know, do an online meetup that translates into an in-person thing. Or if you, if in-person is not your thing, then, you know, figure out how you can build your online environment around that.

I think it’s tricky because it’s not one size fits all, but you know, in-person or async, if you’re a really async person, then, then slack or discord is a great way to go. So yeah, there’s, there’s a lot, there’s a lot there. Yeah.

[00:27:21] Michaela: I think it probably really about personality as well. I think a lot of people really enjoy.

Writing and, you know, participating in this estrone coroners conversation, even though they are often very synchronous right in discord. That’s why I always feel like I missed that conversation. Oh, I missed that conversation as well. And then I just leave without writing anything like anyway, so the last question that I have for you is you just started as a technical community, like.

What, what are you doing dead? Are you doing actually the same thing that you just learned yourself? And you’re not like your master now and the expert here for, for deep gram or what’s your role there?

[00:27:58] Bekah: Yeah, it’s kind of, I [00:28:00] feel like it’s such, it’s been such a good fit for me. My background, I spent 10 years teaching college English.

And so deep gram is a speech to text. AI company. And so there, there are so many different experts in different fields there. So, you know, whether it’s data science or linguistics or engineering and, you know, the devil team I get to talk to everybody and. Understand where they’re coming from, but I sit on the dev REL team as a technical community builder, so I can do dev rally things.

I can write if I want to I can contribute code, but my focus is on creating those systems and processes for community and the external community at deep gram. I always say that your community starts with the internal community. You want to make sure that you have a strong internal community before trying to start an external community, because you have to have that support network to help you and that trust to be in guidance.

So I’m doing. You know, some educating I am doing well, hopefully some speaking in the near future and hopefully some writing and building out that community strategy and trying to figure out, you know, where, how can we. Fill a need in the tech community or how can we support existing communities out there?

So it is, it’s pretty much a mixture of everything I’ve ever done in my life to this point. And it’s been really fun in the first three weeks now having a team to work with them. Yeah,

[00:29:31] Michaela: it sounds super exciting. Yeah. I can’t imagine everything coming together for you. And you can really strive now with the competencies that you, I think not only developed you probably had already from the beginning, right?

Because it’s not something that you. You make the first virtual coffee? I think a lot of people did that and then it grows into something that’s, you know, so probably not in the deaf community as well, so well rounded. So yeah, so [00:30:00] congratulations to that. And thank you so much for sharing so much about the process and about virtual copy, how it worked.

Yeah, I really enjoyed it. Is there something that you want to tell our listeners? Maybe how can they sign up for virtual coffee? He said, you know, do you, do you have to have some commitment there or accountability?

[00:30:21] Bekah: That’s a great question. So we make everybody come to at least one virtual coffee for before getting an invitation and to our slack and that’s to, you know, help them experience, you know, our community and to see what it’s like, because, you know, we feel that we demonstrate that pretty well in those meetings.

And so it’s really. Figuring out if it’s in the community for you, because it’s not the community for everyone, we all have different needs and, and things that we like. And don’t like, and so if it’s for you, then it’s great. Then join our slack, fill out our new member form. You can find those events@virtualcoffee.io slash events.

So come and check out a virtual coffee and then.

[00:31:05] Michaela: Yeah, cool. I will link everything in the show notes. And thank you so much for talking to me being here today with me. I enjoyed it.

[00:31:14] Bekah: Great. Thanks so much. I’m going to, can I mention one more thing? Yeah, sure. I just want to say to ’em if you follow deep gram devs on Twitter, I think we’ll be running some very cool Twitter spaces through there soon.

So if you want to check out some Twitter spaces, you can do that as well. And thank you so much for having me. This has been great. Yeah, I really

[00:31:35] Michaela: loved it. Okay. Thank you for caring. Thank you. Bye

[00:31:38] Bekah: bye.

Are happy developers more productive?

Are happy developers more productive? Let’s look at some research together and explore whether happiness and satisfaction affect developer productivity.

How to build a strong engineering culture through engineering values

Learn how engineering values can help you build a strong engineering culture and empower your developers to make decisions that are aligned with your goals.

Measure developer productivity using the SPACE framework

Dr. Storey explains how to best use the SPACE framework to measure the productivity of software engineering teams. Dr. Storey is a Professor of Computer Science at the University of Victoria and a distinguished expert in empirical software engineering.

We talk about:

  • Productivity metrics for software developer
  • Developer experience as a different mindset to improve developer performance
  • The SPACE framework, which focuses on giving a well-rounded understanding of developer productivity. 

Book your awesomecodereview.com workshop!

Subscribe on iTunes, Spotify, Google, Deezer, or via RSS.

Transcript: Measuring Developer Productivity with Dr. Margaret-Anne Storey 

[You can help make the transcript better, and improve the podcast’s accessibility via Github. I’m happy to lend a hand to help you get started with pull requests, and open source work.]

[00:00:00] Dr. Michaela Greiler: Hello and welcome to the software engineering unlocked podcast. I’m your host, Dr. McKayla. And today I have the pleasure to talk to Dr. Margaret-Anne Storey. Dr. Storey is a professor of computer science at the university of Victoria and a distinguished expert in the field of empirical software engineering.

[00:00:18] I had to pleasure to work with Dr. Storey on many occasions. Even this year, she joined me during a research I led on developer experience, looking at what makes developers happy and productive and leads them to stay longer and more engaged in their job. Today, I have her here to tell us more about developer productivity and especially, I want to know how can we measure it? How can we improve it? And so I’m super happy to have Dr. Story or Margaret-Anne, or actually Peggy how friends call you. Here on my show. Peggy. Welcome to the show.

[00:00:52] Dr. Margaret-Anne Storey: Thank you very much, Mikayla. It’s great to be here.

[00:00:55] Dr. Michaela Greiler: In the last episode. I talked about my perspective on developer experience and developer productivity and well sort of, there was a little bit of a conclusion, uh, bottom line, which is that I think organizations and teams should stay right away from focusing on measuring develop. productivity and more think about developer experience. This means like, how do the developers feel about their work? Are they, are they feeling productive or are they happy? You know, do they feel that they make progress? Are they bothered by some tools and so on? But what is your take on measuring productivity?

[00:01:32] I know you did a lot of studies there, so you have a lot of expertise. What do you see? think?

[00:01:37] Dr. Margaret-Anne Storey: All of my research that I’ve done over the last few years has really pointed towards taking a lot of effort and understanding what you mean by productivity before you try to measure it. So what does productivity mean to you? I know that in your last podcast, you mentioned the space framework, and that is the summary of a lot of years of research that shows that, that there are many different dimensions to productivity.

[00:02:01] To some people it’s about pull requests or lines of code they committed or features delivered to the customer or ability to be able to learn something new or help other people. You can’t just say that there’s one way to understand productivity or define it. There’s many different ways and consequently, there’s different ways of measuring it as well.

[00:02:23] It’s interesting to say that we shouldn’t measure productivity, but the fact is a lot of companies will still try to do that. And I think a lot of developers also try to think about how productive am I being? Am I being as productive as I think . I really like this pivot towards thinking about developer experience, which is what we worked on together.

[00:02:45] And you invited me to join that wonderful project that you’ve worked on. And I loved that because a lot of my earlier research really distinguished developer satisfaction from developer productivity, they’re definitely related. So more satisfied, happier developers will be more productive and feel more productive and vice versa.

[00:03:05] But there is this difference. Developer productivity to me really it’s about measuring what they do, right. Or how they do it. The amount of work that they were able to do, or the amount of value that they provide, whereas developer satisfaction or developer experience is more how they feel.

[00:03:22] And those are two quite different things. So I really like that nuanced change that you brought to that through developer experience.

[00:03:32] Dr. Michaela Greiler: You brought up two things, which I think are also in my opinion, two extreme different things, which is the things that they do and the value that those things bring. I thought about this, especially in my entrepreneurial journey it even impacts me much more, so that everything that I do should also lead to impact and have impact and have value.

[00:03:54] Sometimes I see in literature that it’s productivity versus performance where performance, a little bit more output oriented. But even there, I think it’s really hard to grasp . So what is productivity? In my last podcast, I was comparing it to the industrial age where we really have off producing something which comes back to lines of code, and impact has nothing to do with lines of code.

[00:04:16] You can have one line of code in. it can have a huge impact. It can be a drastic bug, or it can be a line of code that really is such a satisfying thing for the customer. I think there are really a lot of nuances, and I wonder, people very often, I see them measuring productivity because it’s the easier metric. I actually really liked the SPACE framework. I’m super inspired by it, but I’m also a little bit skeptical on the metrics side of it. I think it’s so great to have it as a mental model to think about productivity in all those different variations. But then on the end we have like these metrics that are very isolated and then we try to stick them together.

[00:05:01] As I understand it. Right. You’re the expert here. So I I’m happy to hear much more about that, but so we should have different dimensions and take at least three or something. Um, but then in the end, like we were taking very different metrics and how are we going to combine them? What will the combination tell us?

[00:05:18] Can we even interpret it? So these are all questions that are racing up in my hat. What do you think about that?

[00:05:25] Dr. Margaret-Anne Storey: I’m not a fan of developing a lot of metrics, honestly. Let me just maybe step back a little bit and just remind our listeners what the SPACE framework is about in case they didn’t get to listen to your last podcast, which by the way was great. I loved your discussion. SPACE framework is very much an overarching framework to think about different dimensions of developer productivity. The goal behind it wasn’t so much defining metrics, but just thinking about when we talk about productivity, what are the dimensions about productivity that we may mean, or other people may mean. So SPACE is an acronym, and the first letter is S and that stands for developer satisfaction and wellbeing. If we think about understanding developer productivity or improving developer productivity, if we make some change, say to improve developers productivity, we need to think about the impact of that change on developer satisfaction and developer wellbeing. The second one is P which is performance. So performance or the outcomes or the quality of the work that you’re doing. And again, what performance means really varies from developer to developer, engineer to engineer, or managers. They all have different views about those performance outcomes that they care about.

[00:06:44] And then the last three dimensions, the A is for activity, which is what a lot of people think about when they think about development productivity. They think about lines of code. They think about pull requests. They think about features that are delivered to the customer. So that’s kind of the typical one that developers tend to think about when you ask them about developer productivity. C is communication and collaboration. In the research that I did with now, thousands of different engineers, when you ask them, what does being productive mean to them?

[00:07:15] For many, they say it’s about collaborating with others. How well I helped others and how well I collaborated with others. And that’s not surprising because software development is such a collaborative activity. You don’t write code by yourself anymore. And then finally, E which you also touched on is how efficient I can be. My ability to be able to get my work done without a lot of interruptions and my ability to get in that very pleasant flow state, so that I really feel immersed in the work that I’m doing. The work that I’m doing, isn’t so challenging that I feel overwhelmed, but it’s at that sweet spot of being challenging enough that I feel that it’s very rewarding.

[00:07:53] Arty Starr also talks about flow in her book called flow about software development, and talks about the joy of development, which relates again to that experience and developer satisfaction. The SPACE framework honestly is very high level because it impacts all of those things, right? It impacts how developers feel their satisfaction and their wellbeing, the performance.

[00:08:15] So the quality, the outcomes of the project that you’re working on, or the tasks that you’re doing. And then it also looks at the activities that you do and then how you collaborate with others. And then that efficiency and flow part, which again, relates into satisfaction and has an impact on performance.

[00:08:32] So these dimensions, they’re not stand alone dimensions. Maybe you make a change that makes developers feel more satisfied and their wellbeing goes up. So for example, you make a change that allows developers to spend one day a week learning something new.

[00:08:47] That could have an impact on their ability to collaborate with others. If they don’t all work on that same day, they won’t hear back from others and it might have an impact on their activity, at least in the short term. So you have to think about these together. In the SPACE framework paper that we wrote about, we spent a lot of time talking about these different dimensions and the fact that there are these different metrics. None of us, I think really believes that, okay. Take SPACE, choose three dimensions and then choose three metrics and you’re done. That’s not really the best way to use it. However, doing that would be better than choosing one metric.

[00:09:26] The benefit from space comes is thinking about these different dimensions and thinking about. What is it we understand about these different dimensions. What do you, and I understand about activity and what that means to have more outputs. When I say software quality, what does that mean to you? What does it mean to my peers on my team? What does it mean to my manager? What does it mean to my manager’s manager? And when I say that I’m spending a lot of time collaborating. What does that mean to you? And what does that mean to other people and so on. So really thinking about those different dimensions, realizing that any change in one is going to have an impact on the other dimensions and coming back continuously to reflect on those and to reflect on how do we each think about these and how do we each think these will be affected if we do make a change to try to improve overall.

[00:10:18] Dr. Michaela Greiler: One thing that came up also in the developer experience work that we did is this idea of between short-term and long-term. And I think, especially in measurements are falling short in that regard, right? With your example where you have wellbeing coming or going up because they’re spending one day learning and then two other dimensions going down because now they have less overlap for the collaboration and they are writing less pull requests or lines of code. There’s also another dimension, which would be maybe learning right. And learning then in terms of what’s actually the performance of the engineers? Do they create better things, maybe they are inspired and all this becomes really intangible. How do we measure it? Is it happening right now? Maybe it’s happening. We see this. If you measure the things wellbeing, let’s say we have a survey and we ask people and we see well-being goes up, then we see from Git, well, the commits go down. We see maybe collaboration overlaps go down. We can measure that as well, but what’s really hard to measure here is that, maybe somebody has an innovative idea. Or maybe somebody had this idea and learned something and this saved us from a bug or created the more maintainable software system because of the things that they learned here.

[00:11:35] This is a little bit my critique point here, and I really like your stand on it. It’s just a mental model to help get all these different dimension, a little bit more organized, because there are so many things floating around. So this helps us looking at the SPACE framework.

[00:11:50] We can at least go through some of the dimension and we’re not measuring it, but we make a thought experiment like I did right now and say we have a very strong feeling that in the long run our engineers will be more innovative. We’ll be up to date. They will learn. They will maybe stay longer with us. I know that for every job that I was stuck, where I felt like I’m not learning. I was very unhappy . And I think a lot of engineers are like this, they want to learn. so I think maybe it’s a nice mental model to think around those things.

[00:12:20] Dr. Margaret-Anne Storey: That’s a really good summary. I’m going to just mention some of the more recent work that I did with Brian Hopkin and Tom Zimmerman, where we looked at alignment between different developers and their managers in terms of how they define productivity.

[00:12:34] And we also ask them how they define software quality. And what we found is that there are many, many different views of what productivity and software quality mean. If you’re saying to somebody, should we use this new tool? Should we allow engineers to spend time learning?

[00:12:51] You have to unpack what are all of your assumptions about what the impact of that change will be on developer experience or the quality of the product, whether it’s in the short or long-term and literally expose all of those assumptions, but also expose what it is that you don’t know.

[00:13:11] If we make this change or introduce this new tool, what are the things that we need more information about? And often enough, I’ve sat in on a lot of meetings and people are using terms like productivity and quality, and it’s clear that they don’t even mean the same thing. And yet they’re in these meetings trying to make decisions, and these decisions are very strategic and the decisions are often made without really unpacking.

[00:13:37] We have comfort when we have signals of what’s going on, but software development is a very complex sociotechnical activity and you can’t reduce it to these very simple metrics.

[00:13:49] This came out in the work that we did too Mikayla, but not everybody’s the same, right? Some engineers might be happy not knowing what the impact is and they may be happy helping the people around them. And that’s what they really care about. I helped four people today.

[00:14:06] I’ve worked with people like that. They’re not egocentric at all. And they’re less focused on understanding the vision. They’re happy to help the people around them. There’s no single way to measure this, even if we use surveys as well.

[00:14:19] Dr. Michaela Greiler: There’s so many good things that you just said that I want to touch upon. why are organizations striving for measurements? the higher up, the more we want some tools. We want to understand the world. And I think it’s this idea of models. Of abstractions, because it’s just too hard to grasp. So if you are the team lead and you have like five engineers. You probably have a really good idea of how things are going.

[00:14:45] Are we productive. Are we performing and so on? If you then the manager of managers and you have a team of 50, I think it’s really hard to understand everywhere. Like, are we doing good? If you have an organization of 500 engineers, it’s like, I’m flying blind, right? I’m still really, really skeptical about building a model, which is so abstract that every model is wrong, that it doesn’t reflect the reality.

[00:15:12] And it doesn’t really help us. And I like what you said about, there are things that we know, but there are unknown unknowns? We don’t even know what we don’t know. And I think a lot of. Our activities in engineering or some of the else is about the unknown unknowns.

[00:15:27] We have to make decisions with the information that we have right now, to the best of our ability. And I’m really wondering if those metrics, if they’re helpful, or is it just that we feel that it’s helpful? Maybe it’s, I think it’s maybe helpful for somebody that has some agenda, right.

[00:15:43] So they want to come up and so now to make the metrics look great. And it’s, again, this short-term vision of, oh, I want to Excel here. I want to be the VP of engineering here. So I make this because it’s easy, right? And even if you have like five or six or seven metrics, we can tune them.

[00:16:00] We know that we can make people respond to it. We can’t show that this is really the outcome that we strive for longterm, but it enables us maybe for some hidden agenda. And it’s more personal than what we are actually going for this main goals. What’s your perspective on that?

[00:16:19] Dr. Margaret-Anne Storey: I think that a lot of organizations use metrics because it helps have a handle on complexity. If I can somehow measure what’s going on, then I can have confidence that the decisions that I made last week or last month or a year ago were the right decisions. Or I might get data back that indicates that those decisions were not right. And that we need to make a change. Good managers know that there isn’t just one metric. They’ll know that there’s a host of metrics. And I think really good managers and really good leaders will also listen and ask the right questions to find out more nuances, more deeper understanding about what those metrics mean.

[00:17:02] I’m not saying don’t use metrics. Use metrics and also have rich insights and be continually reflecting and revisiting your assumptions and thinking about, you know, what are are your goals.

[00:17:15] Are our goals to sell more of our product? Well, yes. Right? Because we need the money to be able to make sure that our developers are well paid. But once we’ve done that what else are our goals? Is it to improve the culture so that when people come to work, that they feel secure and they feel safe and happy and they have psychological safety.

[00:17:33] Is our goal to retain our really best talent over the long-term and, and how will we do that? Understanding those goals and then understanding which of these metrics from a whole different set of possible metrics, I think is one thing to do, but really looking at what do our metrics tell us.

[00:17:52] But what do they also allied? Right? What do they hide? What are they wrong about? What is our data gathering? What is our data not gathering? Every time we define a metric, what risk are we introducing by using it? And what else do we need to gather? Like maybe some stories or insights to give us that full picture.

[00:18:10] That’s why I think the SPACE framework is quite powerful because it helps us kind of identify a whole set of things that we need to ask questions about and that we need to listen to those answers, to be able to make better decisions in the future and make change.

[00:18:26] Whether it’s change to address a problem or change to make some kind of improvement. There’s a lot of different things to consider and it’s an attempt to get people to slow down and not to rush, to define metrics and then create a dashboard and then look at it once a week and say, look, our numbers have gone up, wait a minute what’s happening behind the scenes here.

[00:18:46] Dr. Michaela Greiler: So what comes to my mind when you talk about that is the goal question metrics framework ? And it’s a little bit of a different approach. I always say, do not measure productivity. You know what I mean by that is in this very simplified way. I think the data is so, so powerful. And I think those things are two very separate areas. The critique that I have for how people use it is that they are creating metrics. But they’re not data driven. I always felt like this connection because you had the same thought about data-driven investigations and research, which is we combine qualitative with quantitative. I personally really think that they’re only in combination, they become powerful.

[00:19:32] I think that only qualitative isn’t as powerful, only quantitative can be extremely misleading. This is the metrics area that I’m talking about in the net critiquing so strongly. But I think that if we combine them, this can be extremely powerful.

[00:19:45] In industry, it hasn’t really landed. It’s also quite complex to combine that to have mixed research approaches. And behind the research approach, there is also a hypothesis. Questions that have to be tackled and so on.

[00:19:59] I’m consulting organizations, where we look at their data because I think it’s so powerful and it can help us guide and make decisions in this very complex world. But I’m always missing this qualitative aspect that we actually go and say, what does this mean? And so coming back to code reviews, it’s turnaround time is on one hand super interesting metrics. On the other hand, it’s completely meaningless. If I take it as face value, if I built a dashboard and I’m printing out turn around time there it’s maybe meaningful for the first week. It only becomes meaningful if I do the qualitative work which means that now I’m digging deep and I’m trying to understand what’s happening here. Why I’m seeing this number? Is this even a number that I should take at face value?

[00:20:51] Dr. Michaela Greiler: Probably not most of the time, not. And I wonder how can we bring that to industry ? How can it be applicable and manageable for industry what’s your take on that?

[00:21:01] Dr. Margaret-Anne Storey: Oh, that’s such a great point. I think that there are a lot of cases of industry that do use mixed methods and do use qualitative data and quantitative data. I’ve seen some examples of this and I’ve seen some examples be used really, really well. I don’t want to mention any company or any person in particular, but I saw it with large companies.

[00:21:23] And I saw one colleague in particular. He went and he sat and he watched developers to see what their pain points were. And that was incredibly valuable to identify some really easy to solve pains.

[00:21:37] Dr. Margaret-Anne Storey: Another example, this was more research that I did with, with Microsoft and we published this in our Tripoli software or my student, Laura McCloud. She was looking, we were looking at the data and looking at the. And she was going around and following sort of jumping from office to office and seeing what happened behind the scenes.

[00:21:57] The code review tools collect all of the telemetry of what happens that the tool records, but it doesn’t record the engineer jumping over to somebody’s office and saying, ah, by the way, I just tagged you in a, in some code that needs reviewing. Do you think you could do this quickly for me?

[00:22:13] Or, oh, I see that you submitted this code and it’s got this really big problem with it. Do you want to fix it before you really send it to me to review it? Because they don’t want to embarrass somebody by finding a big bug. So understanding what kind of happens behind the tools and behind the data is really, really critical.

[00:22:32] Sharing examples of this with companies and showing them why that’s powerful to have these rich quotes, these rich stories. about what’s going on to augment the data, to go hand in hand with the data, I think does shift how people approach it.

[00:22:48] Data only tells us what’s happening. It doesn’t tell us the why. It doesn’t tell us what we should fix. It doesn’t always tell us what is actionable in here that we can change. So we may see over time that engineering productivity, according to the activity metrics goes down. But that doesn’t tell us why it’s going down, necessarily. We have to observe, talk to developers to find out what’s going on here. Why are you not committing as much code as you used to? And then by talking to them, you can then get insights that help you make changes, and then you can use your metric to see, okay, is there a change? Do we see this change?

[00:23:26] Dr. Michaela Greiler: And I think especially with that one, it could be just a change of how people use the tool. Maybe they squash commits and we are commits

[00:23:34] Dr. Margaret-Anne Storey: Yes

[00:23:34] Dr. Michaela Greiler: Right.

[00:23:35] Dr. Margaret-Anne Storey: Yeah.

[00:23:35] Dr. Michaela Greiler: I think the, the biggest problem here also is that okay, if you have one team it’s normally quite simple, but if you have several teams and they have very different work styles, then, these numbers really become meaningless.

[00:23:48] I would love to find more ways for organizations to bring that insight . This ability to actually have metrics. But not only have metrics really have measurements. I distinguish between measurements, investigations instead of metrics. I define it once and then, half a year later, they are outdated. They’re not reflecting reality, but I’m measuring and I’m having data. I’m looking at data, I’m doing investigations . This investigation mindset. I think that would be so strong for organizations and the ones that I’m working with I see so many really good results. It’s almost like enlightenment ? Where metric is a light somewhere making a little bit, in the dark, something visible.

[00:24:28] Dr. Margaret-Anne Storey: The other thing that I’ve come across is that a lot of folks in industry think that interviewing or observing developers is very time-consuming and it doesn’t have to be, you can learn a lot from sitting with your team at lunch and asking them, what are your barriers? What are the challenges that you face? How is your experience. And gathering those insights just even once a month can lead to a lot of insights that you can then use to make change.

[00:24:59] Dr. Michaela Greiler: I think one perspective that I also want to add here is that this qualitative aspect that I’m talking about, doesn’t always have to be talking to people or observing people. It could be that there’s a person that has this task and they’re going in, they’re investigating, let’s say 50 pull requests. And they writing down what’s happening here, or the last three bugs, why did that actually happen? Some quality metrics or if you’re thinking about metrics again, metrics for me would be oh, line coverage. But then a person really doing the investigation going and saying, why is this project so different in line coverage than that project ?

[00:25:36] Or why are people having those large pull requests over here and not there? And very often, if we then do the work, and I call this also qualitative, because you’re not collecting data. It’s not quantitative. You have to look at it, you have to investigate and you have to see, oh, actually this is very coupled ?

[00:25:52] This is the reason maybe there’s a framework.

[00:25:54] And metrics, don’t tell you this story . And I think that this is really what’s so important for engineers to improve the experience and to improve their productivity, their performance. To reduce their pain points

[00:26:06] Dr. Margaret-Anne Storey: Actually, you reminded me of one good example when you talked about coverage We did this study that I mentioned that looked at the quality, how developers define quality and how managers defined quality. And we have this framework called truce, which is the timely delivery of robust features that delight users, support future collaboration and future evolution of the product. This definition of quality came from the developer and managers words that they gave us in the survey we did. Again, there are five dimensions ? Quality you can think of according to these different dimensions and test coverage is quite interesting because that would fall under robustness.

[00:26:48] That you have really good tests for the code that you’re delivering so that it will potentially catch some of the bugs that you have in the code that you push out today. But you might also have tests that don’t necessarily cover the code as it is today, but are there to support change in the future. So they allow you to make changes in the future. Obviously they cover the code still, but they’re more focused on not finding bugs today, but allowing somebody else on my team to make changes in the future. So how do you tease that apart? Understanding what it is that you’re looking at is really, really critical.

[00:27:24] Metrics, if you use them or measurements, any measurements, if you use them in a blind way, you’re going to be missing that nuance and they’re gonna get stale. And people will misuse them. And they’ll be abused and they’ll be gamified. So really bringing that nuance in is critical and addressing the misperception, I guess, that it takes a lot of time to bring that extra information and it doesn’t . We need to think about it and build a culture that it’s important to ask these questions along all of these different dimensions.

[00:27:56] Dr. Michaela Greiler: I think there also have to be role models. But I totally agree with everything that you said. I actually think we are at the end. I’m so happy that you were here and I definitely will invite you again.So thank you so much, Peggy, is there something that you think makes this conversation a little bit more rounded that is still missing from this productivity idea?

[00:28:17] Dr. Margaret-Anne Storey: I guess, just to sum up that if you’re thinking about developer productivity, also think about developer experience, and also think in terms of quality, like product quality and to really kind of think about those three independently and to think about if you make some changes or you’re making decisions, what are the dimensions of each of those three things? What are those dimensions that you need to think about? And if you’re working with other people. Find out what their assumptions are. If you’re talking in a team and somebody is talking about developer experience or developer productivity or software quality to say, hang on a second, what does that mean to you? Even if you do that, I think it’ll shift the conversation in the room quite a bit.

[00:29:03] Dr. Michaela Greiler: Unpacking their assumptions, this is so powerful. So thank you, Peggy. Thank you so much for joining my show.

[00:29:09] Dr. Margaret-Anne Storey: Thank you so much. It’s been great.

Driving innovation and engineering practices with Dr. Holly Cummins

In this episode, I talk to Dr. Holly Cummins. Holly was the development practice lead for IBM Garage for Cloud, before becoming an innovation leader in IBM’s corporate strategy team. She drives innovation for companies in various industries, such as banking, catering, retail, or even nonprofit organization. She is also a Java Champion, a JavaOne Rockstar, a published author, and a regular and vivid speaker. 

We talk about:

  • What it takes to drive innovation in an organization
  • Test-driven development (TDD)
  • Ensuring a healthy and welcoming company culture
  • The benefits of Pair programming

This episode is sponsored by IBM – where innovation and transformation come together.

Subscribe on iTunes, Spotify, Google, Deezer, or via RSS.

Transcript: 

[If you want, you can help make the transcript better, and improve the podcast’s accessibility via Github. I’m happy to lend a hand to help you get started with pull requests, and open source work.]

Michaela: Hello and welcome to the software engineering unlocked podcast. I’m your host, Dr. Mckayla and today I have the pleasure to talk to Dr. Holly Cummins. This episode is sponsored by IBM. IBM not only produces and sells hardware, middleware and software, but also offers hosting and consulting services. The part that is the most interesting to me, is that IBM is also an active research organization, and an enabler for innovation and transformation. One interesting business area is called the IBM garage – which focuses on accelerating digital transformation, by helping people generate innovative ideas while it also equips them with the practices, technologies and expertise needed to rapidly turn those ideas into business value.

Dr. Cummins was the development practice lead for IBM Garage for Cloud, before becoming an innovation leader in IBM’s corporate strategy team. She drives innovation for companies in various industries, such as banking, catering, retail or even nonprofit organization. She is also a Java Champion, a JavaOne Rockstar, a published author and a regular and vivid speaker. So what should I say? I’m super thrilled to have Dr. Holly Collins here with me today. Holly, welcome to the show. 

[00:00:56] Holly: Thank you so much. It’s yeah, I’m really looking forward to our chat. 

[00:01:00]
Michaela: Yeah, me too. I mean, my introduction was really, really long because yeah. You have so many accomplishments. It’s really cool to talk with you. So how does that work? Driving innovations for organizations? Can even one person drive an innovation for a whole organization? Or do you need like, that everybody is on board. How do you. 

[00:01:21] Holly: I think one person can make a whole organization innovate, but one person can help create an environment where innovation flourishes. I think we’ve certainly all seen the opposite as well. One person, if they do it wrong, can really best innovation across the whole organization. And I think. With innovation. It’s about making this sorts of environments where ideas can grow and where there’s the second, the logical safety for people to express ideas, but then also the organizational tolerance for risk too, to be able to invest in those ideas. But then also I think you need some methodology or, or some rigor to try and. Manage your innovations, because I think a lot of us have as well have seen innovation labs where there’s all these amazing ideas and then none of them actually make it out the door of the innovation lab. And that’s fun for everybody, but it’s not really moving things forward. And really what you need is innovation that matters. 

[00:02:29]
Michaela: Yeah. . I’m currently working on a research project where we look at cultures, especially for development teams. How do they have their cultures? What makes them happy? What makes them productive? What makes them innovative and psychological safety and, you know, being able to speak your mind. This is also important. And I conducted a couple of interviews. I also have worked in different organizations and it’s just really tricky, right? I mean, it’s really tricky to be in a work environment and being able to voice your opinion. And some people get really lucky, but a lot of people really struggle with that, I think. And I don’t know if it’s, if it’s bigger organization, I can’t, can’t even say like a bigger organization. It’s more tricky than in, in smaller. I’ve been in startups. So you think, well, innovation should really flourish down. There were like brilliant people on the team, but they’re are also. They take all the space, right. They’re very dominant people. So then all the others conferee so much, then there are like larger organization where you can strive. Is there some recipe that you can recommend for people to, you know, follow to get more psychological safety or do you know, be, be more self-aware if others even can speak their mind or, you know, like, how does that work? 

[00:03:40] Holly: Yeah, that, that that’s yeah. Super interesting about the startups. I I sometimes feel at a disadvantage talking about culture cause I’ve worked for IBM, my whole career. And IBM clearly is not a startup. It’s about as opposite a startup as, as you can get in terms of its history. But one of the things that I. Like to talk about, which I think is probably quite related to your, to your research is the importance of fun in the workplace. And I deliberately talk about fun because it’s a little bit provocative because we all have this sort of instinctive reaction that says work is a place for work. It’s not a place to have fun. And so then. I think by sort of choosing something that seems counter-intuitive and then peeling away the layers to talk about why actually that fun environment is really closely correlated to a productive work environment. And I think as well, it’s, it’s quite closely correlated to psychological safety. And I think, you know, the psychological safety manual, certainly doesn’t say let’s have achieved psychological safety by, you know, installing. Ping-pong or, you know, that kind of thing, but, and it’s, you know, and I think what I mean by fun as well, it’s not those sort of that superficial layer of fun. It’s that, that deeper thing where you feel the connection to your colleagues and you feel the work gives you joy. 

[00:04:55]
Michaela: Yeah. I also saw that coming up in my own research, but also related research, right. That satisfaction, happiness and productivity. They are really concepts that are very intermingled. ? So engineers also having fun if they are feeling productive and productivity also means connectiveness. ? So a lot of developers that are interviewed, they talk about supportiveness and how they have to know that there is another person that I can. Call or no call before we could walk up to them, but now we call them and they are there and they’re helping us. If you’re stuck, we don’t see the siloed. Right. There’s a friendship coming up as a concept. Right. People want friendship in their workplace. Yeah. I can totally relate to that. I felt really lonely last year working as a solopreneur. And so that’s also why I stepped a little bit away and was taking on more customer work again, because now I’m in teams and I’m feeling, you know, I’m talking to people more and this is really, I mean, it’s also joy and yeah, so I can totally relate to that. How, how do you engage with organizations? So you are at IBM, but you got into different other organizations or is that all internally where you have like little labs that you, you know, that you try to get to flourish? 

[00:06:09] Holly: So my role at the moment it’s somewhat internal and somewhat external. We’re always working with clients, but sometimes I’m working with an IBM team who is working with a client, but in, in the garage we were, we were very outward facing client facing. And, and I think there’s, there’s lots of different answers for how do you engage with an organization? How do you change an organization? Right. The, the answer that we chose in the garage is really sort of support at the top and then making the change bottom up. So we would try and get buy-in from the senior stakeholder. And the organization wanted to try working in a new way that it wanted to try bringing some of these, the psychological safety in the innovation. But then also some of the other things that we talk about a lot, like, I mean, agility is an overused word, but that, you know, that ability to respond to change that, that tolerance for risk. But I think sometimes know. If if we try and make that change only at the top level, then it just ends up being as a lot of words on slides and so in. And, and there’s a lot of resistance to these ideas as well because people work in the way they work for a good reason. It’s not like everybody’s sort of set out and said, I know we’re going to make our organizational cut culture so that it, you know, crushes the spirit and destroys productivity. You know, the intention was always to, you know, to try and achieve something good. It’s just that the side effects. Yeah. We’re not good. So then what we do is we work with a particular team on a particular project, and we say, we’re going to, we’re going to do this particular thing and we’re gonna get a result and we’re going to do it in this new way. And you can see that while we work in this way. Actually good things are happening, not bad things. And bringing in dev ops, for example, hasn’t increased the, the odds of something bad happening. Look, we can show you it’s reduced the odds of something bad happening, and look, it’s actually made the process more rigorous, even though the process is also more seamless. And so if we can do it on this one project, that’s maybe not super business critical, let’s try and now expand it to the next project that maybe is a bit more business critical. That, that ripple I would affect because I mean, I think success is the best evidence. And so when you can do something and show the results, then that makes people much more keen to try it for themselves. 

[00:08:32]
Michaela: Yeah. So you are coming in and then you’re working with one team. And is it only you, or is it you and the team that’s working with that other team with that project? How does that work? 

[00:08:41] Holly: Usually we’d have a team. And I think the, sort of the, at that teamwork aspect is, is so important. I think going back a bit to what you were saying about the lockdown that even the most introverted developer, I think, you know, we, we get something. Team and the, the effects are much better as well. So we try and have really diverse teams in terms of the skills and the disciplines of the people. So normally what we would have is we’d have a handful of developers. We’d have maybe some, some architecture support. But then we’d also have designers who are really making sure that we’re focusing on. The humans using the technology rather than just look, it’s a thing and it’s shiny and I can install it and I can write code on it. And so I’m happy, you know, trying to sort of reel it back, but I’m glad you’re having fun Holly, but how are we making life better for someone else? And, you know, what’s good. You know, cause success for any software project. It’s not just, I did code success is something is better somewhere either at a business level or, you know, at a user level or that kind of thing. So on, on our side, we try and have this really diverse team, but then we also want to make sure that we’re co-creating with the client. So our ideal is that they’re bringing their developers along. They’re bringing their architects along. They’re bringing their designers along as well. And then they’re bringing a product owner because they’re the one who owns the vision for what we’re trying to do. And then that means that as well as making the thing we’re doing a skills transfer. And so I when I was first working in the garage, one of our, the the IBM sellers who we were working with got a bit grumpy because the, the sort of model that they had done was that we would do a thing and then they would sell training for the thing. And because we were. Co-creating that training just sort of happened on, on the job and it didn’t slow anything down. So we would be pair programming and that knowledge transfer would happen. And it would happen in both ways as well. So we, we know things about the carriage method that we can share. We know things about test-driven development dev ops, but then, you know, they’re going to know things. Or organizational context to say, ah, yes. When you want to do this, you need to tell, talk to Bob on the second floor. And so having the person who knows that pairing with you means that you don’t sort of have to go through this elaborate process of I’m stuck. Who do I talk to you? And then, you know, try and figure it out. And they know things about their, their business domain as well. And you know, the sort of the, some of these problems are really quite specific and niche. And, you know, you couldn’t have just a general consultant go in and solve it without doing that. Co-creation. Yeah. 

[00:11:24]
Michaela: And how long are those engagements normally until there is some transformation and some knowledge transfer, how long does it take 

[00:11:31] Holly: for the license? I don’t think the sweet spot is about six weeks, so that’s, that’s long enough to do something that’s really meaningful to get an MVP, but it’s short enough. That an organization will feel okay with the risk. Cause, you know, if we, if we sort of say, and, and, and as well, you want to make sure that at the end of it, those results are going out and are really visible. So having that short cycle and then say, okay, and if we’ve done it once and you like it now, let’s do it again because. You saw that result and it wasn’t this sort of really protracted process where it took 12 months to see any change. Yeah. 

[00:12:10]
Michaela: So you are mentioning already a couple of development practices, like Def ops test driven development, and you have, I mean, the development practice lead for IBM garage. So. Do you think, what are some of the development practices that you recommend that really everybody should do? Is it like peer programming? You also mentioned that or code reviews. What about testing? Do you think this is crucial? Do they have to do it? Can we just do it a little bit? Or can we just skip some of those things?

[00:12:40] Holly: Yeah. We sometimes have conversations about testing because. The there’s a trade-off I think between doing something quickly and failing fast and getting that rapid feedback and not over-engineering while you’re doing that and the enormous benefits of testing. So sometimes if we’re doing something that we know is going to be throw away, and I think there’s a lot of value in doing something that you know, is going to be thrown away. That is that, you know, sort of lean startup , methodology, maybe testing doesn’t make sense. But I think in general, The, the benefits of testing are so great in terms of the quality of the code, but also automated testing is absolutely necessary to support dev ops and dev ops is really. Necessary now in order to support any kind of automation and efficiency and any, you know, that, that ability to do those repeated deployments and the ability to respond, to change and to manage risk. Sometimes, you know, you sort of hear these stories of something that goes wrong and then an organization doesn’t have any way to make a change to fix the problem, except either to go through. Lengthy process or to completely short circuit and bypass the process and, you know, have someone secure shell into the effective machine. And then they change the things by hand, which is obviously not going to be particularly robust in terms of the repeatability or the safety or anything. So you sort of get this chain where you. Do dev ops, because I know it gives so much better results in order to do DevOps. I need to have automated testing. If I’m going to do automated testing, I want to do it with test driven development, because that gives so much better quality for the tests and it. ensures the testability of the code and as well, I think one of the biggest benefits of test driven development is really to refine our understanding of the problem as well. Some people call it tested and design rather than test driven development because of that effect that when I sit down, I think we’ll see, what am I really trying to do? How will I really know what I’m successful? Let me write a test for that. And usually what we look for with a test is something that we would have been looking for manually. Anyway, you know, I go to a web page and I see this, or it prints this. It’s always, you know, we’re always looking for some evidence. We just try and encode that, looking for the evidence in, code, which is efficient. Usually. 

[00:15:09]
Michaela: Yeah. So test driven development often is I see it a little bit synonym to also unit tests instead of integration tests. But now you also mentioned something like a UI test, for example. So do you have, like, do you make some distinction here and do you think one is better than the other? Do you see that there’s a shift nowadays in industry? I see a shift and a little bit that, what is your perspective on that? 

[00:15:33] Holly: Yeah. I mean, I like to do test driven development at, at all levels. So I like to do test driven development for my integration tests. I like to do test driven development for my unit tests. I think sometimes you do get a little bit tangled where you can’t have, you know, you sort of, you, you do your, you write your unit test and then it passes. And then in doing that, you’ve done enough that actually your integration tests is already passing. So then you’re. Catching up with your integration test a bit, but sometimes we do it the other way and we say, okay, I’m going to start with my integration tests. I’m going to get those integration test passing. And then I’m going to fill in a bit with the unit tests. But I think like, I don’t think it’s something that is just for one level. I think if it’s an outcome that you care about and that you don’t want to regress, then there should be an automated test on it. I mean, I, I. I’m a huge fan of contract tests as sort of an intermediate layer between the integration tests and the unit tests. Cause I think sometimes with unit tests, well, integration tests are really expensive to run in any kind of complex environment, especially once you’ve got 60 microservices. Good luck running the integration tests in any kind of regular way. But then with the unit tests, I think you can sometimes get the sort of abdication of responsibility where everybody owns their microservice and they run their unit tests and everything works great. And the system as a whole doesn’t work. And so somebody has to care about that at some point, but then you sort of end up playing this sort of. Sort of pass the parcel of responsibility, where everybody goes more, my services working as designed. And so then an on all the problems happened at the seams. 

[00:17:13]
Michaela: Yeah. , my PhD thesis was about playing in testing our plugging systems and how you test them. It was more or less also services, service oriented architectures at that point. Right. And it was pretty new. People were just jumping on that vegan and so on. And I said, well, you know, you were going to get a little bit into travel if you’re, if it stayed the same with how we are doing testing and nowadays but you’re also an expert for cloud computing. Would you say that in the cloud world, somehow testing or in general engineering practices change, is there, do we have an impact we should we or can be developed in a different way, test, deploy everything. Why is said the same? 

[00:17:54] Holly: Yeah, I think it has to be different in order to take advantage of the cloud. So one of the things that you’re almost certainly going to want to be doing on the cloud is, is that DevOps it’s that more rapid deployment. And then if you. Deploying rapidly. And you don’t actually know if your code works, then either you’re going to have an enormous issue in production, or actually you’re not going to be deploying rapidly, you know? So we still sometimes see these cycles where something is getting deployed to the cloud, but then there’s a three week UAT phase before anything can be deployed. And so then. You know, that just doesn’t work. It’s a waste of the cloudiness. It almost may as well be on-prem. So, so you sort of get this ripple back from, again from the dev ops, which you want to be doing to the testing to the TDD. 

[00:18:42]
Michaela: I also think like we had, we had very strict roles back then. Right. So whatever, like operations. Yeah. The engineers, the software engineers or developers. And we had like the testers, then there was like a time. Now we have this dev ops for, you know, at one point for dev ops, I feel like every engineer was supposed to be a dev ops engineer. And and then we had like the full stack. So you’re not a front end or back end, your full stack, your full stack from front end to back into dev ops to everything. And now I feel people start to struggle with that concept again. No everything because there’s so much to know that there’s not a single person that can be like this end to end dev ops engineer to front end you know, genius. You see dad, like is there, is there again do you see that there are more roles that are forming itself or a person is bringing more Def of engineer and then more of backend, more front end, you know, cloud maybe, you know, even more concepts that we have here.

[00:19:43] Holly: Yeah, that one’s a really tough one. And I, yeah, I sometimes sort of, and I think I sometimes talk to people who ha, who say exactly the same as you, that, that there are too many expectations on me and actually trying to do all of these things means that not only will I not be quite as good in all of them, actually, I’m going to be pretty inadequate in all of them. And are you sure that’s what you want? And so. I think there probably is, is a space for having those specialist roles. But I think part of the issue as well, sort of is there’s an organizational decision about where do you, where do you put the boundaries? Because I think we probably still do want to be saying. That if you are too specialized, it creates organizational friction because it means that you risk becoming a bottleneck or, or the opposite as well that it, you know, it means that you risk not being deployed because all of a sudden, none of the projects our organization is working on, have a need for your skills. And since you only do this one thing really well. You’re just going to be sat around and that’s not great for us cause we’re paying you and it’s probably not great for you either because you’re really bored. So let’s try and have everybody at least be able to do a few things and let’s have people really comfortable sharing their skills as well. Cause I think that comes back a bit to the pair programming and the multidisciplinary teams that maybe I’m pretty sure. Pretty bad at front end, but I know just enough front end that if I’m collaborating with a front end developer, I can bring my something else. And we’re still going to do a better job than if that front end developer was on their own. And we’re going to do a way better job than if I was trying to be a front end developer on my own. And so then you get these sort of complimentary skills in, in the pairs. 

[00:21:37]
Michaela: I think we are coming back again to the teams as well, or to the concept of a team. And that people are really strong as a team. Maybe they are. And there was like, I did an interview with it, very senior engineer. And what he said is like, , if you want to go fast, go alone. But if you want to go far, go with the team or with people. Right. And so this was indeed in one of the interviews about productivity and happiness and so on. And I think. I was also talking to Alex from FedEx and she was on my podcast. He’s a testing expert. And she was also talking about these teams where you have like a person that has a strong expertise, but then this expertise somehow overlaps. Right? So you want to expand your expertise to other roles. Let’s say you are a testing expert, but then you want also to understand development a little bit, then you want to understand maybe dev ops a little bit. Right? And so you’re having this. These shapes that are overlapping. And then in the same team, you have a person that is very similar to what you said, right? They are front end expert. And so you’re overlapping in your understanding each other quite a bit. Right. It’s good. If you don’t, if you’re not solely responsible for everything and you can learn from each other, I think learning is also such an important concept for happiness. Do you see that, that people want to learn? 

[00:22:47] Holly: Yeah. A a hundred percent, I think it’s, it is one of those things that motivates you at work. Isn’t it is, is that desire to learn and, and, you know, if you just do the same thing every day, it, I mean, it’s, it’s awful. Isn’t it? There needs to be something coming in. And I think you’re right. That, that does come back to that teaming that if you’re working in a team and people have different skills than you, then you’re, you’re automatically going to be learning. And one of the things that I always said about pairing in particular is, you know, there’s sometimes we put sort of a hierarchy on pairing doughy and we say, okay, so we’ve got the senior developer pairing with the junior developer and they’re teaching everything they know to. It always, it always goes in both ways. So as a senior developer, if I’m pairing with a junior developer, often they’ll know a framework I’ve never heard of. And so then they’ll teach me about that and they’ll know keyboard shortcuts. I’ve never heard of. So they’ll teach me about that. And so it’s always that, that two way knowledge transfer in, you know, independent of your position in the hierarchy or how long you’ve been anywhere. Yeah. 

[00:23:50]
Michaela: So I hear you talk a lot about pair programming, so. I don’t hear you talk about code reviews. What do you think about them? Do you do them, are they not that important? Do they compliment or do you don’t need them, if you do poor programming, how do you see 

[00:24:03] Holly: that? So my, my, my personal take is that one of the great advantages of pair programming is that it eliminates the need for code reviews. And we sometimes talk about You know wait, isn’t pair programming, more expensive. I’ve got two people doing the work of one person and, and, you know, there’s all sorts of reasons why that’s not true, but I think one of them is that otherwise you have, usually you will have a para-pro code review process at the end, otherwise, and that can be really expensive, so it can be expensive in terms of people’s time, but then it can also be expensive in terms of the sort of thing. Bottleneck and the blocker that it creates, and it can be expensive as well in terms of the, sort of the patterns that it encourages. Because if people know that when you put something in for code review, it takes three days to get it back and get it approved. You know, that’s maybe a pathological case, but it’s not that pathological people. Aren’t going to be putting things in every 10 minutes. You wait until you’re finished something and then you send it over and then you get this. Spiral where the person who’s doing the code review gets a mountain of code and they go, Ooh, I’m not, I’m not looking at that until I’ve got a bit of room in my schedule, which is three days later. And then as well, when they look at it, usually. I see a couple of things happen. One is that because it’s so much work, if there’s a really fundamental design problem, either it’s sort of too late and they can’t see it, or they do see it, but they think, oh man, you know, they’ve been working on this for three days. I can’t go back and tell them they should have done something completely different or that they shouldn’t even written any of this code. And so then the sort of the big problems don’t get fixed and. But then you think, well, but I’ve got to show that I did the review. I’ve got to show that I’ve got some value in this process rather than just annoying them by waiting for three days. Let me find the position of the semi-colon line 36. Let me comment on that. Then everybody knows I’m contributing. So you get this sort of bike shedding. And as you can tell, if I find the whole, the process for us one of the patterns that I really encouraged with the pair programming is that you rotate the pairs every day. So that gives you a much deeper code review. Cause I think otherwise you only, you get like one person’s code review, but then you sort of end up where two people can be wrong just as easily as one person or two. Certainly, you know, two people can be wrong. So then on the second day, A third person comes in and then there’s already sort of another built-in code review where they, in order to be able to contribute, they get walked through what was done the day before. And then they’re able to say things like, oh, well, but why did we do this? And here, why don’t we just try this? And it it’s, you know, it’s not a formal review. It’s an interactive sort of getting them up to speed teaching experience, but then it means that there’s this second chance to catch errors before. Developed too much, but I think, I mean, I think you probably are. You’re asking the question cause you, you probably have quite a lot of expertise on code reviews and you’re gonna tell me all the patterns where it does work, which of course it can, then it can work 

[00:27:07]
Michaela: with no, no, but I definitely did the recall and realize all the things that you said, because this are definitely really common problems that I also see that teams have. Right. So this is also one of the things by in my view, Teams come and they bring all really everything that you said, right? Like, and this whole chain of how it just doesn’t work. Great. How to process doesn’t work and where you, where you have this waiting time, where then the code reviews are too big, right. Or you’re done, cannot understand them. You still have to do them. What do you do? Right. So this, there is definitely this, this loop that you are describing. Totally recall, because this is, you know, this is the, the problems that all the people are bringing on the table when they’re coming in, when I’m working with it. Maybe what I see, I actually really liked code reviews because of this synchronicity. Right. So you can have them in a very lightweight way. I also see them complimentary a little bit to peer programming, but you definitely have to do them in a different way. Right. And I think what many organizations don’t understand and why we are creating this loop of yeah. Troublesome problems that we have, how we doing is that we don’t understand the goal of why I’m doing this. Right. What do we want to get out of that? And then also, okay, what do I want to get out of that? And how can I shape the process in a way that I’m getting this out of that? Because I really see that they have all these painful drawbacks. Definitely. But they also have like really wonderful benefits. So I think the most important is that you really understand. The pain points that you said very, very deeply, but then also, what can you, you know, what can you do to counteract them? How can you change your practice but, but I see, I see all the things that you say, and I’m actually a big fan of pairing as well. For me personally it’s very draining to do it. Like I love it from time to time, right? Like it’s the best where I feel like. You have your mentor there, or, you know, you have just this connection and the supportiveness with the people. So I totally enjoy it from time to time, but not too often. How often do you do pairing? 

[00:29:17] Holly: So what, what we used to do. In the, in the garage is, is we would do it pretty much all day, every day. And there was, there was a few advantages to that because I think one of the, sort of the hardest things of pairing is the logistics. And so then going back to the PA to the code reviews, you know, there’s some circumstances under which pairing just will not work and makes no sense because it’s, it’s so synchronous and asynchronous doesn’t scale. So, you know, you need to have that kind of asynchronous process as well. And if you’ve got Particularly, you know, if it’s something like open source where people are in different times zones and they’re working different schedules and some of them are doing it in their own time, you know, something like pairing it, it, you know, it’s almost off the table to, to begin with. But what we found is if we tried to be. Ad talk with our pairing, which of course works quite well for a lot of teams. We sort of, we never ended up doing it because it would be well let yes, let’s pair today. Yeah. We definitely want a pair today. Okay. So, so maybe after lunch. Oh, I can’t after lunch, I’ve got, you know, I’ve got a thing. Okay. Well we’ll maybe, maybe at two o’clock. Oh, I can’t. And then, you know, we, we settled that we’re going to start pairing at three o’clock, but then something would come up and then somebody would be unavailable. So by sort of defaulting to pairing, we’d keep our calendars free. And it was great actually, because if we got invited to. I’m afraid I can’t attend this meeting. I’m pairing. So if you interrupt me, you’re interrupting my hair as well as it was sort of, it was like this sort of intro we could block your time. 

[00:30:43]
Michaela: a couple of organizations that are working with and That we try something out and it looks really, really nice is that you’re doing code reviews on a particular time. And then it’s done by one engineer. Right. But they’re doing all the others can go in and now everything is via suit, right. As are our teams and whatnot. Right. So by that video conference, and so they’re doing this cultural view, right? Everybody that’s interested can join. Right. And those sessions really, really particularly work well. I’m very surprised by that, but I really have good feedback from, from different organizations where you know, you have this casual thing where people know this is happening, right. One person really drives the review and the errors can watch ask questions, clarification questions, or, you know, other things maybe learn just have their fairness. Have you tried something like that? Is that 

[00:31:36] Holly: we’ve tried some similar things? Not, not exactly like that, but that, yeah, that seems, seems really good. So we did I mean, one pattern of course is the sort of the mobbing pattern where we say We don’t just want to do it with two people. We actually particularly for knowledge sharing, you know, we want to do it with six people. So let’s all gather around the keyboard or let’s all gather on the zoom, but as well, what we used to find was, again, it’s that scaling that the pattern I described, where you rotate the pairs every day in a big code base. With a big team is still gonna be quite a while before you rotate round. And so then you do need something else. So what we’d sometimes do is on a Friday, we’d do a show and tell session. So it was, it was very similar to what you described actually, but we’d sort of someone would say, okay, well, I’ve just done this particularly evil thing in this part of the code base. And nobody’s sure. Yeah, understand what I’ve done unless I talk them through it, or I’ve just discovered this really counter-intuitive behavior in this library. Let me show you all what it does. So you don’t get called out the same way I did. So it was sort of partly a code review and then partly a, an education session, but it would just be really informal and just whoever had interesting code. Would show it and talk it through the rest of the team and then they’d ask questions and that kind of thing. 

[00:32:46]
Michaela: So maybe one last thing that I would like to talk a little bit with you about is because you. You actually transitioned a way, right? From, from being this development lead at the IBM garage. And now you’re an innovation leader in the corporate strategy team. What does that mean? And what, what’s your role there? What do you have to do? 

[00:33:05] Holly: So our, our, my role in corporate strategy, it’s really interesting. It’s because I’m sort of in the, you know, we’re sort of a headquarters role, so I’m sort of in the, in the heart of IBM in, in the center of IBM and I sort of get to see a lot of what’s going on and what we’re trying to do is we’re trying to. Really just be the, sort of like a free resource, both people and financial to try. And when we see something amazing that can’t quite happen because there’s some sort of blocker or there’s just, you know, it just needs a little bit of money to, to get over a starting line that we can sort of give it that, that push. And then hopefully. Make something amazing happen so often it’s where if we have a client team and you know, the client really wants to do something and we really want to do something, but just somehow it just needs a little bit of money just to demonstrate to the people who have the large amounts of money that this is really worth doing. And, and one of the things that we do as well, because I think as an industry, we’ve, we’ve moved a lot now, too. Every, you know, we always want to be trying to do things by actually trying them out rather than doing slides. So that that’s not, it was new when the team I’m part of was started. It’s not, it’s not new anymore, but still in a larger organization, you still sometimes get things that fall between the cracks where it doesn’t quite fit in, in anybody’s mission. But that means it’s actually extra important. So then, because, because we’re sort of central, we can bridge those, those internal barriers. 

[00:34:39]
Michaela: And do you still have a lot to do with engineering? Do you still develop software or is it more really strategic and leading that you’re doing right now? 

[00:34:49] Holly: It’s a little bit of a mix, which I think going back to what you were talking about with the learning and the, and the variety, I think it is good. So it means that whatever, whatever seems most necessary. We’ll do that. So sometimes it’s actually let me go in and architect this, let me, let me go in and out a bit of code. Let me, you know, I’m not a data scientist, but some of my colleagues are data scientists and they’ll okay. Let me fix your model for you. And then sometimes it’s more strategic and more making those connections to say, actually, I can see that this is going on in one part of our organization and something complimentary is going on in another part of my, let me connect those two, and then we’re going to get a better outcome. 

[00:35:31]
Michaela: Oh, that sounds like you’re really having a lot of hats. I really liked that when I was at Microsoft, also driving bit innovation there and having all these different hats, like you’re, you’re driving projects, but you’re also doing the implementation. I was mainly prototyping at that time. But it also means that you, as you said, you have to learn a lot. Did it take it a little bit to get used to that role and know what you have to do? Do you have like mentors that help you or is it. Structure around some, formal mentorship program at IBM. How does that work? 

[00:36:03] Holly: I think. With that kind of role where, where you have a lot of hats. I think it comes back to, to the team again and the sort of the resiliency and the team. So what we tend to do, because we’re doing challenging things and we don’t know in advanced necessarily what skills will be required is we, we do sort of go around in groups where there’s more than one of us. And then that means that whatever hat ends up being needed, there’s someone who has that hat and then someone else who can sort of shadow the hat. 

[00:36:34]
Michaela: Yeah. Yeah. That sounds really a great team to be in. Maybe the last thing really last thing. And then I’ll let you go. Or that I want to talk with you about is there’s the same culture eats strategy for breakfast, right? So, and what it means is that. The culture is of utmost importance. But also it’s a very vicious cycle that, you know, how do you get your culture to apply and how do you get your team members to, you know, like each other or at least respect each other, right. Especially if you have, so sometimes people have I also have that in my workshops when we are, you know, when we are working on these problems, that code reviews create right where we have, for example, very strong personalities in a team with very strong opinions. So it have problems, you know, like giving into, what did you hear? Do you have like do you have like some strategies for that? Do people do something to do, do some coaching or can you help can the team help itself? What’s your experience with that? 

[00:37:34] Holly: It’s. It’s tricky culture, because in some ways, some things about culture, you, you can change because you can, you know, sort of start with your small changes and then success is the best evidence. And then you can roll it forward and you can make those little changes to encourage psychological safety. And you can have, if, if the leaders are bought in, then they can make some of those changes as well. But part of it then does still come down to the people in the team. And that is often the thing that is. Most challenging to, to change, but, but even, even people I think are, are changeable. And I think sometimes characteristics that we assume are just this person actually are the context in which we put them as an organization or habits that they’d learned that with the right environment can be unlearned 

[00:38:27]
Michaela: or teamed up that makes maybe right or one person creates or reacts, but only two, right. Person, but to really the whole team dynamics. Are you are you a fan of like bonding sessions and you know, we’re people, what a team really can, you know, get to know each other, do you think that’s 

[00:38:45] Holly: I really like them, but I think they, they need to be done sensitively because they do end up sometimes not being very inclusive if we. If, if we choose something that half the team love, and then some people are sort of stood there going, well, this isn’t really what I wanted. So I think there sort of needs to be some, some pre-thought to, well, there’s everybody in the team going to like going out to a noisy bar or. Does that actually not work. And I’ve seen I’ve had some good conversations with people actually, when I talk about fun, because sometimes we get these sort of bonding sessions that get put into a team and we say, right, we’re going to have fun. Now we’re going to, you know, do our bonding and we’re going to go out to a bar and some people are going to know this, this isn’t fun for me at all. But then there can be alternative. So some teams, for example, they’ll play a board game at lunch. And so it means that people who need to rush home after school, you know, are after work to get kids from school or that kind of thing. You know, they’re, they’re included and people who don’t drink are included and it’s in sort of at work. So then it feels like an extra nice treat. It doesn’t feel like you’re sort of being required as part of your job to go out and do things out of hours, which some people really object to. And so then, you know, and there’s other things like, like that, or. This is a really old example because w w one of the other things that happened when I started talking about fun is lots of people told me about their workplaces and that the terrible unfun things that had happened. And there was a team and they were sort of there were a support organization, so they would work quite long hours and shifts. And it was a distributed team. So what they would do is AF after five 30, they would all play quake or doom or something like that together. And it was sort of back in the day when broadband at home was a luxury. So you would take advantage of your office network and they were, you know, they were, it was completely you know, a bonding thing. And they were told by management, if you’re in the office after five 30, you have to be doing work, which I just thought was. Incredibly short-sighted on the, on the part of the, that management to say, you know, your, your people are not on your time making the effort to get to know each other better and to work better as a team. And not only have you not, you know, encouraged this and, you know, put in money for cakes or something, you’ve actually told them they’re not allowed to do it. Yeah. Yeah. That’s very, 

[00:41:08]
Michaela: very shortsighted. Yeah. Terrible mistake. But sometimes I really like for management, sometimes I really ask myself. How can you make this decision, but you know, different story. Okay. Well, Holly I know we are on time, so thank you so much. I could have, you know, like talked with you another hour, but thank you so much that I could pick your brain about everything, about all your experience and you know, your knowledge that you have. Yeah. It was really wonderful that you have been on my show. Is there something that you want to share with my listeners? Did you think it’s important for them maybe around culture, happiness, fun productivity, maybe a little thing that they can start doing today? 

[00:41:49] Holly: I mean, I th I think, yeah, just to sort of think about those, those, those aspects of fun and, and think about how can I have more fun at work? How can I bring more joy, joy, and delight at work, but also how can I make. Those around me are also having more, more joy into life at work because otherwise it becomes a bit one-sided. Yeah, I 

[00:42:09]
Michaela: think in general, after Corona, I call it now after COVID right. I just say after, because it’s just nicer to say that I think we really have to come back to thinking more about others. I think we haven’t been thinking. Enough about others before, but I think, I don’t know how it’s in, in, you know, in the UK, but it, at least here, I feel people are more distance because of it. Right. And I really think we should think more about each other and you know, what brings us joy? How can we help others? How can we be nice to others? Right. Yeah. And I think this can bring joy again to yourself, right? If you maybe should think about how can I make the day, a little bit better for my colleague today? Or help somebody? I think this can be a cycle of positivity. I dunno. Like, yeah. 

[00:43:00] Holly: Yeah, absolutely. I think we realized one of the things that we realized with, with COVID is how, how much we need others and how it’s, you know, it’s not much fun without others. Yeah. Yeah, 

[00:43:12]
Michaela: exactly. I think so, too. So I hope you all can come back together and then really be nice to each other and care for each other. Yeah. Okay. So Holly, thank you so much for being on my show. Have a wonderful. In them. Yeah. I hope I talk to you soon again. 

[00:43:29] Holly: Yeah. Thank you so much. It was, it was great fun. 

[00:43:32]  Michaela:  Yeah. It was really fun.

Better collaboration & performance through diversity and inclusion

In this episode, I talk to Trier Bryant and Kim Scott who co-founded the company Just Work which helps organizations and individuals create more equitable workplaces.

Trier Bryant is a strategic executive leader with distinctive Tech, Wall Street, and military experience spanning over 15 years and the CEO of Just Work. She’s previously worked at Astra, Twitter, Goldman Sachs, and led engineering teams in the United States Air Force, where she already also drove diversity, equity, and inclusion (DEI) initiatives.

Kim Scott is the author of both successful books: Just Work and Radical Candor. Kim was a CEO coach at Dropbox, Qualtrics, Twitter, and other tech companies. She was a member of the faculty at Apple University and before that led AdSense, YouTube, and DoubleClick teams at Google. 

We talk about:

  • how they both landed in tech
  • their diverse and exciting background
  • how to counter bias, prejudice and bullying in the workplace
  • the framework for diversity and inclusion they developed
  • and how engineering teams can be more inclusive.

Today’s episode is sponsored by CodeSubmit – the best take-home assignments for your tech hiring!

Subscribe on iTunes, Spotify, Google, Deezer, or via RSS.

Transcript: 

[If you want, you can help make the transcript better, and improve the podcast’s accessibility via Github. I’m happy to lend a hand to help you get started with pull requests, and open source work.]

Michaela: Hello, and welcome to the software engineering unlocked podcast. I’m your host, Dr. McKayla, and today after pleasure to talk to Trier Bryant and Kim Scott who just released the newest book, just work. But before I start, I want to tell you more about code, submit the best take home assignment platform to streamline your tech recruiting. Yes, exactly. This amazing startup is back sponsoring. Over the last month, they introduced a lot of exciting new features, such as live coding within a full working ID, running directly in your browser code submit makes it really easy to recruit and hire amazing title, and they support 64 different languages and frameworks and integrate seamlessly with. Beginning of the year when I was hiring engineers for a startup, I worked with, I used the tool during the interview process for all the candidates and was extremely satisfied. Their mission real task. No, brainteasers resonates a lot with me, so I cannot recommend coats. Admit enough, please check them out at codesubmit.io. That is codesubmit.io, but now back to Trier and Kim who founded the company just work, which helps organization and individuals create more equitable workplaces to your brand is a strategic executed leader with distinctive tech wall street and military experience spending over 15 years. And the CEO of just work. She previously worked at Astra Twitter, Goldman Sachs, and led engineering teams in the United States air force, where she also drove diversity, equity and inclusion. Kim’s cough is the author of both successful books, just work and radical candor. Kim was the CEO coach at Dropbox, Qualtrix, Twitter, and other tech companies. She was a member of the faculty at apple university and before led AdSense YouTube and DoubleClick teams at Google. So what should I say, except that I’m super, super thrilled to have both fantastic and super accomplished women here with me through here. And Kim, welcome to. [00:02:00] [00:02:00]

Trier: Thank you for having [00:02:01]

Kim: us. Thanks so much. It’s an honor to be here. [00:02:04]

Michaela: Yeah, I’m really, really excited. It’s also the first interview for me, where I have like two guests here on my shows. I’m so I’m super excited. And I normally start my show with asking my guests how they actually landed in tech. So a little bit about your journey and here, I think it’s really interesting because you both have such a wild, a little bit wild and very diverse backgrounds. So three, I want to start with you. You served in the United States air force. Like, I mean, it’s already makes me wow. Right. And you led engineering teams there. How did you get into us air force. And how did you get into software engineering and how was that experience before. [00:02:44]

Trier: Yeah. I actually got into the air force through, by attending the air force academy. So I attended the air force academy for four years for college and then got commissioned as an officer. And I actually. Wanting to be an engineer. I majored in systems engineering because my dream job was actually to work on the planes. The future planes at the airport was going to build and take feedback from the pilot to make changes. That’s not what I ended up doing. I ended up doing cybersecurity, but that’s what I wanted to do. And here we are, so [00:03:21]

Michaela: okay. And cyber security. So. And did you do that as the U S M U S air force? Or where did you, when you do do that? [00:03:29]

Trier: I did that. I did that for seven years, active duty in the air force, cyber security, primarily defense. So preventing adversaries from getting into the us military is now. Oh, that [00:03:42]

Michaela: sounds very, very exciting. How was that experience for you working with probably quite a lot of man at that point. I mean, maybe that’s a very naive picture of the U S air force. I don’t know. Maybe it’s like equal, but I mean, engineering generally is very heavy, you know, unbalanced work [00:04:00] with diversity. So how is that in the us? [00:04:04]

Trier: Yeah. So that’s actually then how I, I usually say I stumbled into my passion with diversity equity, inclusion, DEI, and that was because there weren’t a lot of women in the military, particularly as an officer in the officer Corps. And as a black woman, there definitely were not a lot of black officers as well. Fewer black women officers. So that’s when I really started to understand what could we do as an institution, both at the air force academy level, air force, and DOD to increase representation in the U S. [00:04:40]

Michaela: And then you have also been at other companies like Twitter and other tech companies. How has that experience, is it different at the us air force or is that very similar? We say, well, people are similar or work. Cultures are similar, you know, problems are similar. [00:04:55]

Trier: Yeah. I think that, you know, every organization has similar problems. I mean, cause you’re dealing with people, but how you may approach them or solve for them will be unique and different. But every company and organization and industry has their own cultures and subcultures within those cultures. So it’s been quite an experience going from a military type of a culture to then, you know, wall street and Goldman Sachs and then two tech companies. But I think ultimately what’s really exciting is that. Really great challenges and really incredible smart people across all of them, but they’re vastly vastly different for sure. [00:05:32]

Michaela: What do you like? Could we generalize that it’s more, that’s more hierarchy there in the U S air force, at least that’s what I would think that it’s very radical and very like order and the, you know, [00:05:44]

Trier: yeah, there, I mean, there’s definitely a chain of command. You, you know exactly how many people in levels there are between you and the commander in chief, the president of the United States, but there’s a, you know, I think the biggest difference from a culture [00:06:00] perspective is. And the military, as I say, everything that the military does is either to save a life or take a life on wall street. Everything at Goldman was about making a dollar, losing a dollar. And then I found at tech, you know, it’s, it’s really just about. What’s been really energizing about tech. It’s like, what is the cool new thing, right? Like what’s the new, cool thing that people want to build or how do you want to solve it? And, and, and building upon that. And it’s been really interesting, but very different cultures as far as like what motivates people to show up. [00:06:36]

Michaela: Yeah. Yeah, I can imagine. Yeah. I like it this very, very, to the point abstracted essence of what it means to work somewhere, right? Like a dollar alive. And now we say, well, the coolest and newest and shiniest thing, even though I think maybe Twitter and, you know, like those tech companies are a little bit more advanced. There are a lot of tech companies that are quite old school, boring tech companies, where I wonder a lot, like I’m doing a study right now. Um, work culture and what motivates people and productivity, satisfaction, happiness, and a lot of people deal with not that new and shiny thing, right. They work with, you know, established technologies and. What I’ve seen from the interviews that I did is that people are not only motivated by, you know, the new and Chinese thing, but really the, the value also that they bring with their, with the product, for example, or sometimes it’s just the people that you’re working with that are very, very energizing and, you know, bring your motivation. And I have seen it as quite diverse and really depending on the company and the environment, people are very, also adaptable to the environments that they are in. When, you know that thing isn’t going so well, they can adjust and focus on something else. Is that also your experience that, you know, even if you’re in a workplace where some of the things aren’t going that well, depending on what kind [00:08:00] of things you’re focusing on, something else, and people are tough. [00:08:05]

Trier: Yeah, I think that that’s one of the things that, you know, professionals that you gain with experience is just how to be adaptable and how to understand, you know, how to make the biggest impact you can with the resources you have and, you know, collaborating together efficiently. And I think that that’s why, you know, just work the book and the framework that we have. Is really being so receptive to tech companies because we, we need to increase. We need to, you know, efficiently collaborate. Like how do we, how do we increase collaboration while also, you know, respecting individuality? And that’s what just work is because, you know, that’s, that’s the two by two that Kim gives you. And if, you know, cam from radical candor, like Kim’s going to give you a two by two and Kim is going to give you a framework. And, and it’s been really exciting too. Have the framework and the book leveraged in that way that, you know, teams are able to increase that collaboration. Yeah, [00:09:04]

Michaela: that’s really cool. I really want to deep dive into that and really understand a little bit more about that. But before we go there, I want to ask Kim a little bit about, about her background, because this is also super fascinating, right? So you manage a pediatric clinic in Kosovo. That’s what I read online. And you started a diamond cutting factory in Moscow. I mean, how, why, how did that come about? I mean, this is really a big change. We were just on vacation with my kids. And I read this article on a guy that, where he was looking for diamonds, and I told him about this to my kids and he actually found one and proposed with this diamond and that, and he was like, yeah, we are going to do that. And I was like, yes, I didn’t even know that it’s still a thing. So how did you do that? Like how did you diamond cutting or diamond timing companies? How does that go? [00:09:59]

Kim: [00:10:00] Well, so I, unlike TRIA, I had a very impractical major in college. I studied Slavic literature, so it wasn’t totally clear when I graduated, how I was gonna, how I was gonna make it. And I wound up, I wound up going to Russia and moving to Moscow and I took a job earning $6 a month, working for Moscow physical technical Institute and what I was doing there. I was the reason why I studied Russian was that I was very interested in. And ending the cold war and then the Berlin wall fell and it solved that problem solved itself. So I wound up in Moscow doing a study on military conversion, sort of swords into plowshares. And, uh, and that was very interesting. But then that company wound up pulling out of Russia and I wanted to stay in Russia. And so. As all things, this is what TRIA and I ain’t going to talk a lot. It all comes back to relationships. So through a friend of a friend, I wound up. Job in Moscow with this, with this diamond cutting factory. And that was actually where my interest in management started was, was I had a higher these diamond cutters, these workers, and I thought that they wanted that they were going to just want to be paid. I didn’t have any notion of management at the time. 22 years old. And I thought it would be easy. Cause I had dollars may have rubles dollars worth something and rubles were worth nothing. And so I went to them and I just said, I’m going to give you this salary. And I just assumed they would take the job, but no, they didn’t just want money. They wanted a picnic. And so we went out on a picnic together. And it turned out after a bottle of vodka. I finally figured out what they really wanted from a leader was someone who would give a damn who would get them out of Russia if things went sideways in that country, as they were apt to do at that time. And, and so that was all of a sudden [00:12:00] management became much more interesting than being just about paying people. It became about for me, Relationships. And as tree are said, learning how to create environments in which we can collaborate and respect one another. That didn’t lead me to attack immediately. That was a longer, I wound up in. I wound up in tech after I, after I, I graduated from business school and I worked for them. I worked for the federal government, the only person in my class to do so working at the FCC. And when I was there, the T this was, gosh, it was long time ago. Now it was in 1996, but the telecommunications revolution was, was in full swing. And that was, that was actually where my interest in tech. Working for the us government. So go [00:12:48]

Michaela: figure. Yeah. Yeah. And so there, you started doing something technical or managing technical people. How, how did you tip [00:12:56] Kim: I, so it’s very strange. So we were trying at the FCC to. And the settlement right system. So it turns out the United States is a net exporter of telephone calls. And because we had broken up the U S had broke it up. It’s it’s telecommunications, monopoly. We, these different telcos us telcos were negotiating with, with PTT that were monopolies and we were losing those negotiations. And so we were exporting billions of dollars in what’s called settlement rights. And those days it was quite expensive. I remember. The man I was dating at the time was in Africa and, and I called him and had an hour long conversation. And while that with a thousand dollar phone bill, so that was, remember those days we forgotten those days. But that, that, that was when I was there. And I, we were trying to end that we were trying to bring down the cost of international phone calls. And as, as we were looking at doing this through regulation, I learned about voiceover IP, and I thought, you know what? That [00:14:00] is the solution. W, and I wound up starting in Israeli voiceover IP company called Delta three. So that was my foray into tech. I thought, oh, well, yeah. Tech could solve these problems of bureaucracy. Wow. [00:14:14]

Michaela: Yeah. So you found it a lot of companies even in different countries and this must be such an. Impressive experience as well. I mean, I moved to several countries, lived there, established a life there, but even, you know, starting a company is another, another step. Right? Like you have to understand how to do that there, how people work, how people think that’s really, really impressive. And so you both together work on chest work. You wrote the book, just work. And now you have a consultancy around that. As I understand it, it’s like. Focusing on recognizing understanding and preventing or fighting injustice. But if you have to summarize it in one sentence, how, how would you say what’s the, what’s the essence of the book and, and why, why would people care? Why should they go and read it? [00:15:08] Kim: So the essence of the book is about really diagnosing and treating the problem of workplace injustice so that we can build the kind of organizations where we all want to work, where organizations that are optimized for collaboration, which is humanity’s superpower and organizations in which we can all respect. One another as tree said before, I don’t know if that counts as one sentence about chair can do it better than [00:15:34]

Trier: me. No, I think that’s, it can that’s that’s the essence of the book. And then for just work, the company, the company helps leaders and organizations build more equitable, productive, and successful workplaces. But what makes the company unique is that the just work framework. Book is definitely part of that, but we meet organizations where they are, because there’s also other things, you know, there’s not a [00:16:00] silver bullet to get this right. You have to have a very comprehensive strategy. And so we provide, you know, a full suite of D and I solutions and products that, you know, can help organizations get there so that they can just work because it takes a lot, you know, there’s not just one thing. That’s gonna get you there, but you have to have a starting place. Right. One of the things that’s just so powerful about the book is that, you know, we don’t have a lot of frameworks. We don’t, I, I have never been familiar with a. Framework that employees can use, that organizations can use, that leaders can use, that you can add to your toolkit. That’s very tactical, right? And so the fact that Kim has really built this and provided this is really powerful that you can point to something and people can easily grasp it and start using it in their every day, you know, in their everyday work situation. [00:16:57]

Michaela: So, what you’re describing is this diagnostic tool for identifying and treating systematic work injustice. Is that also described in the book? And can you describe it for my listeners? How it looks like, how can they imagine it? What does it do? [00:17:13]

Kim: How do we work? Sure. Absolutely. So I think we tend to treat the problem of workplace injustice as though we’re one big monolithic problem. And when we treat it that way, it becomes very difficult to, to, to cure the problem to solve the problem. And so what we’ve done is we broken down the problem into its component parts. So the, the, at the root, the root causes of workplace injustice or bias, prejudice, and bullying. And I think too often, we tend to conflate those three things. We treat. We treat them as though they’re all the same thing, but they’re different. So bias is sort of not meaning it. It’s often unconscious. Prejudice is meaning it it’s a conscious belief and bullying is being mean or meaning [00:18:00] harm. And so each of these, each of these attitudes and behaviors demands a different kind of confrontation. And then when you add power on top of bias, prejudice and bullying, you wind up with discrimination, harassment, and physical violations, and we can walk you through some of the, some of the solutions that we recommend that leaders can put into place and, uh, upstate. Can use so that they don’t get slimed by other people’s bad behavior. And that we can use when we are the person who’s harmed by these attitudes and behaviors. And also how we can respond when we get feedback that we are the person who was harmed. So in some senses, it’s like a six by four. It’s a big, it’s a, it’s a big problem, but six by four is not intractable. So there’s bias, prejudice, bullying, discrimination, harassment, physical violations. So those are the problems. And then each of us play four different roles where either the leader where the upstander. We are the person who’s harmed or where the person who’s causing harm. And one of the things that trio and I are working on doing is, is coming up with very specific interventions for each of those problems. Enrolls. [00:19:13]

Michaela: Yeah, I really liked that. And I think, especially when I was younger, I’ve ended up, I don’t know why I ended up quite often in situation where there was harassment or really bad situations. And I felt like people could already smell that they can step over boundaries and, you know, be mean, be bullying, um, even more. Right. And so, I don’t know. Is that something that you, that you saw, you probably did some research around that and, and very familiar with. [00:19:44]

Kim: So I think that it is one of the things that I have found is that when we, when we observe workplace injustice or we observe that someone is a colleague who we care about is coming into work, having experienced [00:20:00] injustice in the society at large. And if we don’t do anything about it, if we, if we are a passive bystander, Then I find at least I often wind up feeling quite good. And then, and then that wakes me up. And now all of a sudden, not only am I a bystander, I’m also harmed by it, but I also have caused harm by not intervening. And so now all of a sudden I’m playing three of those roles. And so teaching teaching. Sort of bystanders to become upstanders is really important. And then also working with people who are the targets, bias, prejudice, and bullying to know how to respond. Cause it’s it’s. I think we have a default to silence and very often when, when there is a default to silence, then we reinforce the problem. So, so helping people learn how to choose a response. [00:20:58]

Michaela: I also think like I’m coming from Europe and especially Australia. So I don’t want to generalize for whole Europe now. There is in Austria then was when I entered the workforce. I wasn’t really expecting that people were really nice to me. You know what I mean? Like the school system here is already that, you know, there’s like the power hierarchies and teachers can be quite mean and you know, the person is the boss, so they can, they have, somehow people are expecting the boss to be mean and, you know, to be in power and to be able to say mean things. Over time. Very, it took me many, many years and you know, many countries to work on that. I also changed my, my perception and I said, well, what happened at that point where I felt really shitty as a, you know, as a student, for example, with professors or even working at university horrible, horrible work environment, harassment, but really official harassment, like shouting in front of the colleagues. Like the professor, for example, nobody would stand up because. [00:22:00] The new it, but it weren’t like it wasn’t, it wasn’t something that you would say, oh, it’s not allowed. It’s not good. We know it, but it wasn’t really not allowed. And just over time, and those were being in the U S I get more sensible for it. And I was like, this was really unright at that point, I would, you know, like, but it wasn’t, it wasn’t my current. Understanding at that point that this is something that is not allowed. How do you see that? Is that, is that a cultural thing as well? Or it has to do, I think it’s cultural, but it’s also probably with the age, right. That you’re really young and you’re coming into and you don’t know what’s right. And what’s wrong. Is that allowed or not? [00:22:37]

Trier: Yeah, some of that, some of it is culture and how things are communicated, but you know what you’re, I think that what you’re, what you’re getting to are some gaps within organizations, within their people, HR practices, because there’s a need for things to be very explicit and not be implicit. And one of the things that we talk about in the framework is having a code of conduct. Right. And it needs to be very clear. So. People can think and believe whatever they want, but you can’t come into an organization and do and say whatever you want. And so in a company to your point, like it has to be very clear. This is not acceptable, or these behaviors and attitudes are acceptable. And then another part that we talk about in the framework is having, you know, a holder of consent. And that’s another one that, you know, Kim and I have spent a lot of time talking about, about we’re in an organization. Organizations, aren’t very explicit on a culture of consent. Right? So like McKayla, you’ve probably worked at organizations where if we said, Hey, was there a culture of consent in your previous organization or companies? And most people will say, well, yeah, there’s a culture of consent. No, one’s going to say no, we don’t have a culture of consent, but it’s, it’s, it’s implicit. But those are things where organizations have to make it very, very clear. Right. Like in whatever type of documentation employees, reading adhere to that, [00:24:00] everyone can point to it. Everyone understands what it is. And the other thing that Kim and I have talked about a lot is that in this, you know, environment of a pandemic with COVID and people going back into the workplace, having that being explicit is really important because it goes beyond. You know, these physical interactions, it might be more intimate or personal to something as simple as like a handshake, right. There’s culture of consent. And COVID is like, what are we going to do with the handshake? It was interesting yesterday in my building, someone reached out their hand to introduce themselves to me because they’re a new member of the staff. And I was like, I’m never shaking, anyone’s hand again, but we can like nice to me to pull it out. Right. But like, how are companies thinking about this in your organizations or even, you know, you’re in a meeting. If someone wanted to borrow my pen and didn’t ask you just grabbed it. I wouldn’t think too. Now, if we’re in a meeting and you grab my pen and I’d be like, you know what, it’s yours have it. I have plenty on my desk. So, you know, these are some of the things that I think there’s real opportunity for leaders and organizations to really pause, look at the artifacts that they have for their employees that help them understand. What is acceptable, what is expected of their behaviors and their actions in the workplace. And if there’s things missing, then where do we need to add and fill some gaps so that we can get it right. And it’s very clear of as far as like, what is expected of people. [00:25:22]

Kim: And I think also McKayla, I’m sorry you had those experiences in school. It sounds like. Sort of acceptable for professors to bully students. And I don’t think that’s unusual, unfortunately I don’t. I think that happens everywhere in the world to a certain extent. And, but I do, I also think it’s changing. I’m Optum. Well, I’m, I’m an eternal optimist, but I really do. In fact, I learned how to deal with bullying from my daughter when she was in third year. So she was getting bullied on the playground as happens, children everywhere in the world, unfortunately, and, and her [00:26:00] teachers weren’t doing enough about it. I mean, one of the things that trior and I work with leaders on doing is creating consequences, but there were no consequences for this kid who was bullying my daughter. And so she and I were talking about how to deal with it. And I was sort of. Trying to convince her to use what we call an I statement with this little kid and to say, I feel sad when you, blah, blah, blah, blah, blah. And my daughter banged her fist on the table. And she said, mom, he is trying to make me feel sad. Why would I tell him he succeeded? And I thought, oh my gosh, she is exactly right. And so we talked about it and we realized a use statement is much more effective. If an I statement sort of. Invite someone in to see things from your perspective, a you statement pushes them away. So you can’t talk to me like that, or you need to stop now or, or what’s going on for you here. If, if it feels like those first two statements might escalate the situation too much. But the point is with the use statement and the Facebook. You are now in the active role and you’re making the other person, the person who’s bullying. You answer your questions. So you’re not submitting to the bullying and that is really crucial to respond to it. So I think it’s, and I think increasingly leaders are beginning to understand that it is a part, whether they’re a teacher or a manager or a CEO, they’re beginning to realize. Part of their job to tamp down bullying in their organizations. Because if humanity, superpower is collaboration, as we were talking about earlier, bullying is a collaboration killer, and it might work for the person who’s bullying, but it’s bad for the team collectively. [00:27:52]

Michaela: Yeah. One thing that came to my mind is I love to talk about software engineering practices ended [00:28:00] on this podcast as well. And. What I’m wondering sometimes is how, and probably you, as the experts here, you thought about that already. How can some of the engineering practices shape our culture, or how are you doing this? And do you think that they can increase or decrease, you know, diversity, equity and inclusion? For example, cultural abuse, right? There are also studies on biases in culture abuse that, you know, certain, certain types of groups GAD, their cultural views rejected for, you know, for no reason or less of a reason than other people or what I always saw. Like the Friday night beer. Well, like I hated the Friday night there. I don’t drink beer and, you know, it’s very, very stereotypical, but I don’t drink beer and there was no wine, never, ever a wine, right. Or a coal gore, you know, I would even like more, just a soda or something. Right. It’s sort of the Citroen. What is your, what are your thoughts on that and how, how we should, should we reflect on it? Is there something around engineering, testing, code reviews, even there’s Def [00:29:06]

Trier: ops. Yeah. Okay. It’s so interesting. Having been an engineer, led engineering teams, working at tech companies, working very closely with engineering leaders. There was a lot of things that are problematic in kind of the engineering culture and it doesn’t have to be right. That’s the part that. So, so silly is that it doesn’t have to be that people consist, like continue to perpetuate and make a conscious effort not to change their behaviors because it works for that person or the status quo. But we have to challenge the status quo. What are some things that engineering leaders and teams can do? One that I was really inspired. And there’s a bunch of, there was an article written about it and there was a bunch of tweets on Twitter and it got a lot of attention actually from a black engineer that when I was at Twitter, my university recruiting team actually hired, but they created this docu. [00:30:00] And really getting engineers to change even the language that they use, right? Like a black list versus a white list. There’s a lot of problematic language and language is so important in engineering. And so even like going and finding that list and saying, okay, we’re going to change some of this language. We’re not going to use, you know, this language anymore because it just reinforces bias. And, and our, our minds are very, very powerful. And so I think the language that is used within engineering is step one. Right? That’s that’s one, two. What is really interesting is I, I was working with a white man engineering leader. At a previous company once. And he’s a true, I have one of the highest performing engineering teams at the company and they’re all white men. So if it’s not broke, don’t fix it. Like, why would I need, you know, like if, if we’re performing and we’re high performing, like w why does it matter that everyone on the team are white men? And I said, wow, like you, you think if you’re high-performing with just all of these white men on your team, The data, the data and the research is there that we know more diverse teams, outperform homogenous teams, right? Imagine what you could be if you actually had representation on your team. And I wasn’t even my, my engineering background didn’t even align with what he did, but I pointed to an engineer on his question. This was a team that part of their responsibility was to write algorithms. To identify hate on a platform. If you look at most platforms, underrepresented women, first of all, trans women and black women face the most hate on most social media platforms. So if that is the population that experiences the most hate, but yet you have a group of white [00:32:00] men that are supposed to write the algorithms to do find that hate. That’s problematic. Right. There we is that we are, I don’t even know exactly how to do, I don’t know how to do your job, but I just know that it’s not working. Right. And we also know that. These populations are still experiencing so much hate on every single platform. And one of the problems is that we don’t have a people who look like the populations who can identify that those populations have considered the table and have those conversations about like, how do you really define that and make it better? And so I think that, like, we really need to think about representation on the teams for that that’s inclusive for the problems that we’re solving for the communities that it impacted. [00:32:42]

Kim: I think, I think that’s exactly right. It’s so important to be willing, to interrupt bias in engineering culture. And there is a lot of it. And so one of the things that TRIA and I work with with engineering leaders to do is to, to, to begin to disrupt bias. And, and so there are a couple of points to, to disrupting bias. There are a couple of different. The first is you need to come up with a shared vocabulary. So TRIA and I use a purple flag. So if I wave a purple flag, it means either I’ve said something biased or someone else in the room has, and we know that fear. And I know that. So, so shared by other teams we’ve worked with, have you. I come again, or I don’t think you meant that the way it sounded or piece it doesn’t the words matter. But, but I can’t give you the words your team has to choose the words that you will actually use. So come up with the words. The second point is you’ve got to commit to using the body center up there. You know, that bias is occurring in every single meeting you have. So you need to come up with an expectation that bias is going to get flagged at least once in every meeting. And then the third, the third thing to do is [00:34:00] to teach people what to do when they are the person who’s caused harm when it’s their bias, who’s being flagged. So if, if TRIA waves a purple flag at me, I get two choices of what to say back. And she asked the same two choices when I wave one at her. The first is thanks for pointing it out. I’m going to work on not doing that again. That again, or thanks for pointing it out. I don’t quite understand what I did wrong. Can we talk about it after the meeting? And then we do have to talk about it, or if we’re on video meeting, we can drop a link into the chat that explains it. And the reason that it’s so important to interrupt bias is that if we don’t interrupt it publicly and in the moment where we reinforce it. And so I’ve seen this happen, In code reviews, you asked specifically about code reviews all the time, where, where you find that, that people are reviewing. Code of, of, of someone who’s underrepresented very differently from the way they’re reviewing other people’s code. And it’s important, this, this brings us to the second point. So we’ve got to interrupt it when we notice it, but we also need to quantify it to go out, looking for it, quantify your bias and. This means that if you, if you are in your code review, you can quantify how many times someone has negatively reviewed people’s code. And then you can take a look at whose code they’re not going to play review it. And if you notice that men tend to negatively review women’s code more than. Men’s code then you know, that you have identified some bias in your code review. Another simpler thing that I experienced, I was working with a leadership team at a tech company, big tech company, and their bias quantification did not take a lot of effort. They noticed that they had not promoted any women to the executive team at this company. And the [00:36:00] company had been around for about 10 years. So they knew it was a problem. They knew the problem was not the women who worked at the company. They had a lot of great women, so they knew there must be something broken in their recruiting process. And so they invited me to their credit to join their promotion committee, meeting to note because everybody on the committee was man. So they thought maybe I would notice something that they themselves had not noticed. And. There were two people up for promotion. One, a man, one, a woman, both of them had great reputations for being excellent managers, building teams that were very highly functioning and very loyal loyalty. Each of these, these two individuals and. They referred to the man who was up for promotion as a great leader. And they prefer, they referred to the woman who was up for promotion as a real mother hand. Now, who are you going to promote the real leader or the real mother hen. And, and so I pointed this out to them and at first they sort of were like, oh, Kim, come on. It’s no big deal. I said, it is a big deal. This is why you’re not promoting women. It’s like the, the, the subtle ways that language impacts the way you think about people, it, you know, is real and you’ve got, that’s why it’s so important to quantify your bias and then go look and figure out what’s wrong and not what’s wrong with the underrepresented candidates, but what’s wrong with your hiring processes or your promotion processes or. [00:37:33]

Michaela: So you’re saying that we have to be very consciously thinking and looking at bias and what’s going on to do work. And it looks like it’s not just work, but it’s also work all the time on, you know, improving our collaboration our way we work together. More powerful. Yeah. Maybe the last question that I have for you too, as you’re giving workshops on inclusion, diversity [00:38:00] and equity. So. How do that workshop works. And also who should be on the workshop should be asked advocates, like people that are already pro diversity, equity and inclusion, or should we better have the skeptics participate or a mixture, or how are you going about that? Is there a minimum number of people at the company that have to take such a workshop to be, you know, to, to, to get that ripple through in the organism? [00:38:28]

Trier: Yeah, I think that, you know what we have seen and it’s, it’s, again, it’s been so nice to have such a positive response that we can come into an organization and do a, just work keynote for an hour or a half day workshop. And that we’re literally leaving people with tactical and practical things that they could implement. And it’s for everyone right now. Yes, there are. In the frame where we talk about, you know, what do you do? Whether any w if you’re in either of the four roles, like a person who’s been harmed. A person who’s a upstander, which is a bystander who actually intervenes, or if you’re the person who caused harm or a leader, and we can do a deeper dive as far as like what leaders and organizations should be doing. But there’s something for everyone in the framework now just work the company. We also though have a lot of D and I. Seminars that we do talking about language, talking about, you know, what does, how do you reduce bias in your recruiting? What does it mean to, you know, take all this education and awareness that you get and put it into action in the workplace, right? And those are seminars that are for everyone as well, whether it doesn’t matter where you are in your journey. Because for those who actually think that, Hey, I am a, I am an advocate. I am a ally. You know, one of the things that we talk about in one of the seminars, How do you go from being an ally to an advocate? Because allyship is very passive, right? And ally is saying, I’m not going to cause you harm, which is good. Right? We don’t want people to call [00:40:00] each other harm, but an advocate, it says, not only am I not going to cause you harm, but I’m going to through action. Stick up for those who have been marginalized and through action. And, you know, create a platform and uplift those who, who need, who, who have been marginalized and know that like they may not have access to all the same opportunities as you. And so how do you use your privilege in that way to be an advocate? And so it doesn’t matter where you’re at in your journey. There’s something that we all need to continue to educate because. It’s not a sprint and it’s not a marathon either. I hear that a lot of like, oh, it’s not a sprint, it’s a marathon. No, it’s actually not a marathon because for those of us who have run a marathon, there is a destination, right. When we’re very happy about that, but there’s no destination for this. We have to continue to do this work. And you know, the other thing that I tell folks is one of the reasons I love, I love this work is because as long as there’s a majority, there will always be a minority. And what’s interesting though, is that as time goes on, Those audiences and those groups have changed and they’ve evolved. And so it’s, and that means that we always have to continue to the work to understand who are the minority groups that we need to ensure that we are paying attention to that we are representing them and that they are having equitable experiences, just like every. [00:41:15]

Michaela: Is there something that you would say to my listeners that they should take away from this episode? What is like the one tip that they can do maybe from both of you? So we have two tips for them that they can go and start doing just today and in their workplace to make it better and nicer forever. [00:41:37]

Kim: Sure. I think if you can distinguish between bias, prejudice, and bullying and respond to bias, which is just not meaning it with an I statement, which invites the other person. And to understand things from your perspective, respond to prejudice with an it statement. Cause prejudice is a conscious belief. The person means what they say. And so you need to show them where the boundary is. They can believe whatever they [00:42:00] want. They can. Do or say whatever they want. So, and its statement can appeal to the law. It is illegal and it can appeal to an HR policy. It’s a violation of HR policy, or it can appeal to common sense. And it’s ridiculous, you know, to, to refuse to hire a woman, for example, and then last but not least with bullying, which is being mean, respond to it with a use statement. You can’t talk to me like. [00:42:25]

Michaela: Okay. I like that. Very, very concrete. Cool. Do you know one thing that you would want tip that you could give me? Yeah, [00:42:32]

Trier: so I think it’s really interesting. And Kim is the one who really pushed and challenged me on this is that I’ve always said that Kim empathy is the catalyst for change in this space. And Kim would say, We need more compassion. And I was like, I want, no, I want more empathy. And then I really had to understand the difference between empathy and compassion. And so I still do believe that empathy is a catalyst for change, but the change actually occurs through compassion. And the difference is, is that empathy is yes, you are putting yourself in that person’s shoes. You’re understanding what that person is going through, but compassion is you wanting to. Through action. Take that pain away, take that suffering your way, do something about it. And so it’s, I think that it’s a journey, right? There was something that I saw about how you go from feeling sorry for someone and having pity to having sympathy. To having empathy and compassion. And so what I would encourage your listeners is to say, where are you in that journey? And to really strive to get to compassion, which means that, you know, that’s showing up through action and then understanding what that app. [00:43:54]

Michaela: Yeah, thank you. I really like it. Great. Thank you so much. You both for taking the time [00:44:00] being on my show, I really enjoyed it. I will put the book there. If you have other links, I will share them down in the, in the show notes. So thank you so much. I thank you for being on my show. [00:44:10]

Kim: Thank you. [00:44:12]

Michaela: Yeah. Wonderful. Bye. Bye. [00:44:14]

Kim: Bye. [00:44:15]

Michaela: I hope you enjoyed another episode after sup engineering unlocked podcast. Don’t forget to subscribe. And I talked to you again in two weeks. Bye.