Dr. Cat Hicks, Director of Pluralsight Flow’s Developer Success Lab, joins Ben and Eira to talk about why ICs deserve recognition for their contributions to big projects (and how they can get it). Plus: why data is your best tool in getting your manager on your side, the shared DNA between Pluralsight and Stack Overflow, and why “learning debt” can be as big a problem as the technical variety.
Cat’s research centers on the socio-cognitive factors and processes that help people learn and succeed. In her role as director of Pluralsight Flow’s Developer Success Lab, she studies what makes software teams thrive and shares that research with the community so teams can learn from her findings.
In a recent report, the Dev Success Lab explored how visibility can encourage higher-performing teams and better business outcomes.
Pluralsight is an education platform for software developers. Pluralsight Flow, their software delivery intelligence platform, is designed to eliminate developer friction and wasted time.
Cat is on LinkedIn and Twitter.
Today’s Lifeboat badge winner is Kent Kostelac, who gave a terrific answer to One-line if-else in C#.
[intro music plays]
Ben Popper Big topics in data architecture call for big conversations. Big Ideas in App Architecture, the new podcast from Cockroach Labs, invites innovators to discuss their experiences building reliable, scalable, maintainable systems. Visit cockroachlabs.com/stackoverflow to listen and subscribe.
BP Hello, everybody. Welcome back to the Stack Overflow Podcast, a place to talk all things software and technology. I am Ben Popper, Director of Content here at Stack Overflow, joined by my colleague and collaborator, our very talented content writer, Eira May. Hi, Eira. How are you doing?
Eira May I'm good. How are you?
BP Good. So our guest today is Cat Hicks, who is the VP of Research Insights over at Pluralsight, a company that we've worked with a few times in the past that shares some of the DNA of learning and technology with Stack Overflow. And we're going to be chatting about some of the different ways in which developers learn software– technologists, not necessarily just developers, and teams can sort of help themselves feel empowered to do that, as well as help their managers manage them a little better, maybe, stuff that Cat has written about and I think also practices. So Cat, welcome to Stack Overflow Podcast.
Cat Hicks Thank you. Delightful to be here.
BP So I guess for starters, tell us a little bit about yourself. How'd you get into the world of software and technology and this interesting mix of that with social sciences?
CH I love talking about this because I think not enough people know what social science is. So I study people and I study what we call the sociocognitive factors and processes that we need as people to succeed. And I started out in psychology and started out in learning science actually, so thinking about what is it that helps people be high achieving, and also what is it that helps people overcome failure? So when you choose to admit that you failed and tell somebody about that, it turns out that's incredibly relevant to software teams. Working on software projects is really, really hard. That difficulty compounds over the course of people's careers. It compounds between teams. So those fundamental skills around asking for help and learning, they're really, really deep. I have loved bringing that perspective to software teams. So right now I lead a social science research team, actually a lab that studies what it is that helps software teams thrive. We release this research publicly, so I love to do this work and kind of see myself as a psychologist for engineering orgs, really.
BP Yeah, I saw that pinned to the top of your Twitter. And there was four quadrants, all of which I felt I could definitely relate to from our perspective. So when you say that you publish this stuff, is that kind of like how we do with our developer survey, or is this more in the academic mold, like you publish this for peer review and a paper goes up and stuff like that?
CH No, I'd say it's much more like your survey. We kind of are driven by this value of data from the people to the people. So in The Developer Success Lab, the lab that I lead which is sponsored by Pluralsight Flow, we take in all kinds of developers' experiences and we want to share that right back with all the people who are in our research. So it's kind of like open source but for social science. You can download our papers, you can read them. We do have a little bit of a foot in both worlds. So we are, some of us, academics, although not all of us, because I think many, many people belong in the world of data and research that are not just like me. So we do publish occasionally. I have published, but primarily we try to get work out there and share it. That's probably what you saw. My Twitter has one of our recent big research launches, which is a paper that we chose to just freely, it's available to download. That's our work on developer thriving.
BP Yeah, that was the one that I saw that I thought was really interesting. How many developers did you reach out to and how are you able to sort of get in touch with them and get them to participate in the research?
CH Ooh, that's an interesting question. I look to models actually like folks like Stack Overflow doing these big surveys. I look to some of those. There is a culture in the world of engineering, I think, where we want to understand ourselves. So in our lab we try to tap into that. We launched this public survey, we distributed it in advertising links. But we also wanted to show our values in our data collection so we included a lot of communication. We said, “Hey, if you come in and you give us this, we're going to send you the research directly. We're going to email it to you. We're going to try to write materials that you can use to advocate with your managers.” So we've written some blog posts, we've written white papers, actually much more readable, kind of easy to share. We've put together some videos. That all was built in as we were communicating in our initial data collection and saying, “Hey, come in and help us build this. Help us tell your story and then we'll try to do our best with the research side of the house and give you a packaging that you can use to share that.” I think that really resonated with people. That was a big part of it. Another part was that we try to include a donation to an open source software organization. We let folks vote on that. You’ve got to give back to try to learn something,
BP Right, support open source and win an argument with your manager. That's more motivation than most developers need.
CH I have to say, pretty compelling for people, yeah.
EM Yeah, absolutely. What has the response been from the community when you've shared this data back, when you've kind of taught them about themselves? I mean, that seems like that would be really valuable, but I'm just curious how folks have responded to that.
CH Yeah, I'm fresh off of LeadDev London. I don't know if you know the LeadDev conferences, but that's a really great space for work like ours because people are already really interested in talking about the culture of running your team. But even there, I often notice that there is a lot of surprise. Sometimes I say that when you study psychology, you study the stuff that everybody is thinking about but we don't all know that we're thinking about it. So it's kind of like the cocktail party conversation, like, “Hey, how do you stay motivated?” Something that I always notice is this. I will sometimes have a conversation with a CTO or someone in leadership about, “Oh, hey. My research team has learned all this stuff about software teams. Here's how they work.” And we have a big, long, interesting conversation about the constraints of software projects and the stress we're all under, and optimization and efficiency. We have stuff to say about that. But there's this interesting thing that happens, which is sometimes we go deep in this conversation and maybe it's in the hallway after the talk. And then the CTO kind of person usually turns to me and says, “Okay, can we really, really talk about what I'm really worried about, which is the people stuff.” And so I think that people love what we do, but I think there's still this surprise and this uncertainty about whether we can do this for our teams and what it means to bring social science into this space.
EM Yeah, that makes sense.
BP Do you think that there are things that are unique to the work of creating software or the kind of team structure that emerges from that? I liked what you said, which is that a lot of this maybe is psychology, it's human. It might apply to workers on any kind of team, but I'd be very curious to know, breaking that down a little more, are there things you think are more specific to this industry or maybe to some of our listeners because of the art and practice of what they do?
CH Absolutely, I think there really is. I'm married to a biology professor and so I always think about ecosystems. Yes, we all need to eat and we all need to sleep and we all need these things, but we live in our own particular ecosystems and those things have their own dynamics and their own weather patterns and their own places where the nutrients hide in our ecosystems. So I think there is a tremendous amount of that for software teams. So for instance, in our developer thriving work, one of the things that we studied along with learning culture, which you already mentioned, we also looked at developer agency– so whether or not developers feel like they are creators of technical decisions, and you can measure this in some interesting ways. You can ask people, “Hey, do you feel like if you really disagree with a decision and you speak up about it in a meeting or you see someone else speak up about it, is there this sense on your team of this agency?” That seems very important for developers and for the kinds of work they need to do. I think another thing that's really, really clear to me after studying developer teams for a while is that there is this difference between the effort that it takes to write software and the outcome, and there's a lot of stuff happening in the land of effort. There's a lot of things you're trying that don't result in code that anybody sees. There's a lot of research, there's a lot of drafting, and so that I think is particularly important for managers to understand and respect. Because if you don't value that work, you end up in a situation where people feel like half of what I have to do is not counted as productive. So I think there are some very big challenges for software teams in understanding what is the human side of our productivity. And it really is pretty specific to software work, I think, because of the way we need to do this work to write code.
BP That's really interesting. I think if you compared it to a group of engineers that were getting together to build a house after the foundation is dug, you can show somebody that and say, “Okay, we did step one. It was a lot of work, but you can see why it's important.” There might be research about dependencies or why you might want to choose a certain architecture that takes a while, a bunch of the preliminary code that you've written to test things out, but nothing that you can show to a CEO who's at some remove from what you're building. And then frustration if you feel like they don't recognize the work that went in and the twists and turns before you got to the first MVP that you could show off.
CH Totally. I love that house metaphor, but I think that frustration is such an important question for where the industry is right now. And one of the reasons we chose to paint a picture of a really happy team, a thriving team, was that we see actually a lot of this frustration in software developers feeling not understood a lot of the time. And another recent piece of research we finished was about visibility inside of engineering orgs and how much individual contributor developers often feel like they write code and it just goes off somewhere, it just sort of vanishes. And so it's very, very difficult to sustain yourself as a human being if you're feeling like you're just grinding and you're not always seeing where that work goes. That's another specific thing I think that is a challenge for software teams.
EM Sort of understanding where their work fits into the overall sort of value structure of the organization. So I'm a writer. When I write something, I can go and find it on the blog for better or for worse. It's going to be up there kind of haunting me. But if you write a piece of code as part of a larger project, you don't have that sort of visibility after the fact.
CH I think that's right. I think that some people do have that. Some people are good at maintaining their own sense of, “This is my history. This is my body of work as an engineer.” You might think about your really senior people or your tech lead folks, your staff engineers. They are getting a lot of feedback and they have a sense of identity inside their org. But a lot of people struggle to get that, especially a lot of junior developers. And I think that one of the things we've noticed is that people kind of take it for granted that it will just happen. “Hey, if I just do good work, it's fine. I will get recognized, I will get credit, I'll get brought in at the right time,” but that really doesn't actually happen, especially when engineering organizations are very cut off from the rest of the business. So I think that what's so interesting about this is actually that sometimes the smallest amount of work on this could go the most enormous amount of distance for people. So a developer in our research told me, “I remember I was working on a demo feature that we were going to go bring in front of a customer, and no one ever brought the engineers to anything related to customers, ever.” For one thing, I guess, why would we want to? I'm not sure, but in this particular case this manager said, “Hey, you know what? The first time you've ever done this end-to-end, we're bringing you to the customer meeting. Don't stress out about it but just come.” And so they came and they were kind of nervous, but in the customer meeting there was this moment where the manager said, “Hey, by the way, this thing that you just loved that we saw you love, here's the person who wrote it for you.” And this was not something that happened yesterday. They were telling us this five years later or something like that. So those little moments of visibility can actually have an enormous impact on someone's identity as an engineer.
BP That's so interesting. As Eira mentioned, we get bylines sometimes in our writing and that's a nice way, but I do think there's maybe a culture within our company of giving a big shout out in the all hands channel when a big project goes up, and trying to make sure you tag all the right people who contributed here and there. And if you don't have that, or if the work you're doing is seen as maybe incidental, like you said, “Oh, you just built the demo, not the actual feature,” although you needed the demo to sell the customer and to get to the next step, that could be pretty dispiriting. It makes me think about video games where you get to the end and there's title credits, and even the person who put in some work coloring a few pixels here and there is going to get a credit, kind of like a film. And that's not the case for a lot of huge software releases that go out. There's an app, there's no credits page, there's no ‘built by’. So figuring out how to get that either as part of your team, if you're the manager or the lead, or how do you find that as an individual is a really interesting question.
CH I agree, I agree. I think it's one of the big unsolved questions for ENG teams right now. And again, I keep going back to this feeling that I encounter when I talk to people out there in the industry about this, which is that it's such a surprise to people. “Oh my gosh, it makes sense now that you've said it, but I didn't even realize our engineers are so cut off from this,” and I think that we see that in our research. We also see the managers who are trying to create that direct visibility for their reports, they actually feel very stressed about it a lot of the time. So it's great if you have a culture where you can post wildly on Slack whatever you're doing on a company level, but there are a lot of situations where it's not appropriate to do that, or someone would just feel kind of exposed by that, or it's not real to them. So there is kind of a deep managerial skillset to figuring out, “Hey, what does actually keep my team motivated? What makes them actually even remember what they did?” Because another thing I see in our research is that people actually do a lot of work and then they immediately discount it. Engineers are very hard on themselves. Software teams are very in the moment, they're working on the next thing, and so actually maintaining that sense of history might seem like, “Hey, this is obvious. You're going to remember what you did well or what you succeeded at.” In fact, we find a lot of developers struggle with this. So another thing is increasing your mindfulness and actually increasing your celebration culture and a little bit of maybe tracking successes over time, that could be very beneficial because this is a group of people who are very hard on themselves.
EM I'm thinking about an article I'm working on for our blog about imposter syndrome and how developers seem sort of uniquely vulnerable to it, or at least uniquely inclined to talk about it and self-aware about it. And this resonates, what you're saying, with some of the advice that I've encountered that's been given to folks with imposter syndrome is to sort of keep track of their accomplishments and sort of notice and respect the work that they've done. Is that another area where you feel like this intersects with the services that you're offering?
CH For sure. I mean, I think that imposter syndrome is an example of the way we think about ourselves. And we're making decisions all the time about, “Do I belong here?” One of the things that we measured in our developer thriving research was a sense of belonging. Does your developer on your team feel like someone like me really belongs here, as a whole person? And I think imposter syndrome is one type of thing that can get in the way of that feeling. Now I will be totally frank with you, sometimes I have problems with the over-popularity of imposter syndrome as a phrase. It resonates with people because it matters, I don't doubt that. But I do think sometimes we use it to talk about ourselves instead of talking about maybe environments that have been bad for us.
EM I think that's such a good point.
CH There was a great HBR article about this, I think it was titled, “Stop Telling Women They Have Imposter Syndrome.” Let's fix how we measure people before we say, “You are so bad for doubting yourself.” What if you have actually had a career where you faced significantly more criticism? And in fact, we measured imposter syndrome on our survey. I haven't released this yet, so this is just between us. We did find, for instance, women in software engineering struggling more with imposter syndrome, but also that they have different patterns around visibility. So when you're earlier in your career, you get less visibility, and when you're further along in your career, you get significantly more actually. In fact, you might even feel all the way out, kind of exposed, kind of too visible. So I think it's really important to start to ask about all of the different things in our environments that are creating that for people.
EM Yeah, I think that's a really interesting way to look at it.
BP Another thing that jumped into my mind as you were talking, especially about the independent contributor, was the point you made early on about how you do research and making a call out to open source which is very popular among developers. Maybe one of the things that they also love about that is if there's a GitHub page for it, and you can go and see everyone who's contributed or made even a small change, then you do have that byline. You do have your name on there somewhere, and you include that then in your resume and your CV or your website. And so in a way, one of the benefits of open source along with saying that anybody can contribute and therefore we all know what's gone into the soup and know it's safe and that it'll be more likely to update faster versus a closed system like a corporation, is everybody is visible from the beginning. I mean, I guess you could be anonymous on there, but that's your choice. And so in some ways, maybe that's part of what pulls developers towards those projects.
CH Oh, how interesting. As a manager myself, as a leader, I'm always trying to think about,
“Am I giving credit? Am I really doing that door-opening that only I can do because I'm lucky enough to be here in this way?” And I never thought about extending it to our research participants. I love that. I'm going to think more about that.
BP Cool. So one of the things that we sort of focus on here at Stack Overflow is helping people share knowledge in public and recognizing folks who contributed answers, but also people who are curious and asked a lot of good questions. I read an article of yours, “Coding in the Dark,” a year later where you're sort of reflecting on a talk that you gave, and there was a super interesting phrase in there, ‘learning debt’. And I thought this is something that comes up a lot when we're talking to software developers at Stack Overflow and elsewhere– how do I make the time to keep up with the technology that's evolving around me, and how do I ask my manager for time to get up to speed with Python, because now we need that as part of an AI initiative, and that's not what I was hired to do, but it's something I feel is necessary. So define for me a little bit about what you meant by learning debt and maybe some of the ideas that you're working on with how folks can manage that.
CH So learning debt came from a research study that I did looking at developers as learners. I am a learning scientist by background, so that's always a perspective I bring to thinking about how people work, especially knowledge workers. And I think that there's one piece that's really important here, which is that we often hear the word ‘learning’ and we think, “Okay, classrooms. I went to school, I got my degree, or I taught myself, I went through a bootcamp,” whatever, and it's over. That is just not how our human brains work. To navigate our world all the time we are constantly learning. So when I study learning, it's inside of the choices that you are making to solve problems in your work. So that's the first thing that I would say. Developers are not just learning on the weekends or with courses, even though I think courses are great, but they're actually encountering moments where they don't know something and they have to learn all the time. So that's what I studied with this research project, and I found this cycle happening for people who were struggling and it was really, really pervasive. I called it ‘learning debt’. And what it is is this cycle that people get into when they feel like they have to learn for their job. It's required, like the example you just gave, “I have to learn this technology. It has to happen.” But my environment, my team, my manager, my organization, my colleagues, they do not see learning as real work, as productivity. And so I have to squeeze it out. I have to beg for it. I have to ask for it. That itself is actually kind of a negative place to start with this. I used learning debt because it's an analogy to tech debt. It's this cycle that builds up inside of organizations where you're constantly running to catch up, and actually you're only half-getting to the learning that you need so you're only half-implementing something in a way you should, and it is really a damaging cycle. So I've described it a lot more in my research, but in the upshot, learning debt is this concept I think we need to have in the tech industry of what happens when people feel like, “Oh my gosh, learning is not actually the most productive part of my job. In fact, maybe I should just hide it from people.” And we give people this mixed message all the time. So sometimes I give this example of if you have a poster on the wall that says “Everyone can learn here,” but you go into a conversation with your manager and you say, “Hey, listen. I made progress on this, but then I discovered this new thing and I had to spend five extra days learning about it and now I can do it,” and they say, “What a waste of time. You got distracted,” that message from your manager is going to cancel out a million posters on the wall. So we have to have a true, depthful, learning out loud, supporting learning kind of culture in order to combat learning debt. The suggestion that I would make to the question that you started this with– How do I get that from my manager?– I would say don't start with, “Please, can I have this as a bonus extra thing?” Start with it like, “Hey, listen. I am here to figure out how to solve this engineering problem. This is what I need to solve this engineering problem. It's a strategic choice. It's a smart choice. It's highly productive.” Teams with high learning cultures actually are more productive systematically in the industry when we measure it, and they're also more productive exponentially across projects in the future. So bring data to your manager. You can cite our research report if you want to. We've measured it with real teams, and say, “This is not just a bonus, ‘Hey, please give me this because I'm failing.’ This is actually the work of solving these problems for us.”
BP Yeah, I like that a lot. It's not a cushy perk, it's part of the approach we need to be good at this problem and productive as a team in the future. And of course, if you can bring data to that argument, you're more likely to prevail.
CH Amen.
BP Plus, if you say this is technical debt, then obviously developers will take it very seriously, because who doesn't hate technical debt.
EM Yeah. You'll have their attention from the word ‘go’.
BP Exactly.
CH That's right. One of my biggest tips is always to listen. If you think people aren't understanding you, find something that they do understand and hook into that and be like, “Hey, listen. We see the same way about this, and this new thing I'm bringing to you is like this. It's an investment in the same way that we'd invest in the tech debt problem.”
BP Awesome.
[music plays]
BP All right, everybody. It is that time of the show. Let's shout out a community member who came on Stack Overflow, answered a question, and earned themselves a Lifeboat Badge, saving a little knowledge from the dustbin of history. Awarded 20 hours ago to Kent Kostelac, “One-line if-else in C, is there a one-line implementation of the following simple piece of logic.” If you're looking for the shortest, sweetest way in C# to implement that if-else, Kent has you covered. Thanks for coming on Stack Overflow and contributing some knowledge. As always, I am Ben Popper. I'm the Director of Content here at Stack Overflow. You can find me on Twitter @BenPopper. Email us with questions or suggestions for the pod, podcast@stackoverflow.com. And if you like the show, leave us a rating and a review. It really helps.
EM And I'm Eira May. You can find me on Twitter @EiraMaybe. I'm a writer at Stack Overflow.
CH I'm Cat Hicks. I'm the Director of the Developer Success Lab. We're at devsuccesslab.com.
BP All right, everybody. Thanks for listening, and we will talk to you soon.
[outro music plays]