Deeply caring for developer experience

[00:00:00] 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 Ashley Hansberger. Ashley is Director of Developer experience at Tackle io. But before I start, let me tell you about my latest project. Awesome cos.com. Yeah. All my work on Culture Views has now its own dedicated home at awesomecodereviews.com.

You find articles about code review best practices code review checklists, news about the latest research on code reviews and of course workshops and courses I offer around this topic. So please hover over to awesomecodereviews.com and check out my latest work. But now back to Ashley.

Ashley is a vivid speaker and proponent of testing, and she loves to share her experience in conferences during blogging, all about testing and engineering productivity.

Before she was working at Tackle.io, she was the director of DevOps engineering at Black. So I'm super, super thrilled to pick her brain today and, you know, learn all about her experience. Welcome to the show Ashley.

[00:01:08] Ashley: Thank you so much for having me. I'm, I'm so happy to be here. .

[00:01:14] Michaela: Yeah. Yeah. I'm really, really happy.

So I want to start really at the beginning. I know that you have been a tester at the start of your career. Yes. So how, how come that you're now, you know, the director of developer experience, how did you come into developer advocacy and so on, but what's, what's that

[00:01:30] Ashley: path? , I'll try to give the short story, but it might become a long and winding journey, but that's okay.

Yeah, I did start as a tester and, you know, went from manual testing and I'm not even gonna say how many years ago, because it feels like ages ago and it was, but that's okay. . So I started as a manual tester and as many companies go, you know, started to learn automation and really found a passion for leading that effort.

So I went from tester test lead. Test architect into really becoming a technical product owner. How do I start advocating the voice of what is needed technically to balance against the features needed so that we can think about how do we design and create the frameworks and develop the automation that we need to get the feedback loops in place for our code?

That kind of led me down to a path of really thinking about testing and continuous delivery and adopting DevOps principles of like flow and feedback and continuous learning and thinking about DevOps from a culture perspective. And once we had a reorg, I was asked to lead release engineering. Now that became a really interesting experience for me, not knowing a whole lot about release engineering, but being able to lead people and thinking about our infrastructure as code and how do we even test our infrastructure.

And guiding a team of DevOps engineers to be able to do just that. As we develop a microservice oriented architecture, how do we create the, the easiest path forward for a team to spin up a service, develop what they need to, and not have to worry about the underlying architecture behind, behind the microservices that they need to create.

So my team creates the Pav road at that point. But what I really found I was most passionate about was bringing people together, learning how to work together and really focusing on people and their experiences at work. I was also asked you, as you mentioned, I've been speaking in the industry a lot about testing.

But what I really found it was about, at the heart of it, was how do we advocate for these ideas and the ways in which we should deliver software? So I was also asked to start thinking about how do we influence an organization through change for an idea that we wanna implement at, at that point, it was agile and how do we scale that across an organiz?

So I got to start thinking about, well, how do we approach change as humans? And, you know, thinking about the, how our bodies and our minds react to change. How do we move through that change, whether it's positive or negative, we, we need to be able to move through it. And I started really getting interested in the psychology of change and how we do that and influence it through other people.

But at the end of the day, we also have to be effective. And what makes effective. Psychological safety. And so I really started developing not just the, well, what are the things that we're trying to do as a team, but, but how do we do that? And what are the things that we need? And so I really got into a deep dive of looking at Amy Edmondson's work and psychological safety.

How do we apply it and learn about our own teams through those mechanisms and start building the, the underpinnings of having an effective. At the end of the day, what I've decided after a lot of reflection was I'm most interested in our experiences as people in tech, because if we are not having a good experience, how can we truly be our best selves?

And if we can't be our best selves, how can we produce something that is really meaningful in providing positive impact to others? At the end of. We might be able to, but it's not gonna be sustainable. So I've been studying on the side organizational psychology pursuing my master's in network.

And I started developing a program around developer advocacy and thinking about our experiences at Blackboard. But through just luck and circumstance was asked to come implement what I've been building over at Tackle io. So I get the chance to start ground up with a fairly new company compared to my 17 years at at Blackboard.

And just start from scratch. And it is so amazing to have the opportunity to build from the ground up with a team that is excited about this change, excited about how we can think about our experiences in a positive culture and sustain what we need through the growth of the company.

[00:05:40] Michaela: Yeah, that's, I mean, it sounds amazing and I think that what strikes me the most when you describe everything is.

At the heart, you're describing some internal. Focus, Right. Which, yes. Which I often see developer experience and advocacy and so on. And it's always outside focused. It's like we want our, you know, tool to be used by others. So and then, and then you have all these developer experience professionals and people and, and this focus.

But again, it's a customer focus actually, right. and what you are talking about is exactly that. What I'm so interested in is the internal focus. So not how can we, you know, make a good experience for our customers, the developer , but how can we have a great experience for our internal developers? Yeah. You know, that are, that are making whatever, you know, it, it doesn't have to be the developer products.

Again, it can be something, you know, completely, you know, let's say it's healthcare or yeah, it's, you know, whatever software you're actually producing. But how can we look internally that we have great experience and, and, and, and I think from that perspective, it's so natural that you're coming from the testing and DevOps side, right?

Yeah. Because. There is always enough time to program. Well, because you have to. Right. So , you know this, they can't take it away. We have to somehow program, we have to code. Mm-hmm. . But there is not enough time for testing for DevOps, for pipelines, for ci, you know, for, for making sure that we have a good code base.

We don't have technical debt. We have maybe, Good meetings. We have a good culture. We, you know, we understand each other. These are all the things that we can scrape away, you know, and just bare a minimum. Let's code . Yeah. And, and so I think, yeah. So when you describe it like this, it makes sense that you're, as a tester, arrive at a developer

[00:07:39] Ashley: advocacy Yeah.

Role. And think about it as, as a tester early and you know, at the heart of testing, we care about what is the user going to experience, Right? Mm. I got into testing because I cared so much about that user experience. Well, now my users are my, my engineers in the, in the whole program, internal, they are my clients.

And it's not just about the code that's delivered or application that's created. You know, we think about these core experiences that make us effective and productive. And it's not just, did I deliver a. . It's the meaning behind that. Do we understand significance and meaningfulness in our work? Do we understand the positive impact we had?

Do we have variety in the things that we do? That helps us, one, learn and grow first and foremost, but also keep us interested in what we wanna achieve. Yeah, do we have the ability to see it through start to finish? I can't tell you how many projects I started that I've just just ripped off of for somebody else to finish and not be able to see what happened with that.

All of these things that affect like our, our wellbeing and our mental state as workers, you know, really helps drive that experience. And when we can have a good positive experience, we're more committed to our teams and our work and our companies. We become very much tied to the mission of what we want to do.

And we're more likely to stay. So we see higher attrition, we see higher job satisfaction. These are all interconnected things that I'm so deeply fascinated by and want to help just make the best experience possible for anybody. Yeah,

[00:09:16] Michaela: yeah, yeah. I did this study that you, read the paper about it, right?

Last year. About developer experience and what, you know, what makes a good or a bad developer experience, what changes and so on. And we had these factors, right? Mm-hmm. . And I really like to do this, this study because exactly of the reasons you said, right? It's not only productivity, but it's wellbeing, it's, you know, retention.

So there are so many good things that are coming out of a good developer experience. And what I also like, you know, from this experience is, Sometimes if you are in this tech bubble, right? Everybody's like, Oh, engineering is so great. But then we have to think, is it true? Right? Is it true that it's so great or is it just a lot of people are in it for the money, which I think is a.

It's a fair reason to be in it for it. Right. But if you have a good experience, then suddenly it's not only the money why you are in tech, Right. It's also Oh yeah. Because you're having a good experience. And I think a person that's not only because you know of the paycheck and thinks, you know, apart from the paycheck, it's actually miserable here.

they write different software than, you know, the person that says, Well, you. I'm in a, in a high paying industry, but what I'm doing, I'm really excited about. Right. I, I feel committed. I feel yeah, I'm proactive, you know, doing something. I can, you know share my ideas. I have colleagues that help me.

This is very different things, and I, and I think those people that have a good experience in their work, they deliver a complete. It's game changing, you know, the, the kind of software Yeah. And product that they are delivering. I mean, that's, that's my experience. How do you see that?

[00:10:52] Ashley: Mine too. You know, I've been on the, the teams that were, became feature factories ultimately, and that was that, don't worry about the experience of the people, just get these things out.

I've been on teams that have really focused on the human aspect. Right. And it's just night and day experience. The, the difference is so vast in what drives somebody to want to, to deliver the best software. At the end of the day, I mean, I don't think nobody shows up and goes to work. I'm gonna deliver crap software, Right?

No, but. It makes it so much easier when you know you have a team you can come in and talk with and ask for help and learn from each other and have clarity in what you're trying to achieve and the processes that help make this as easy as possible. I don't know if, if you've had this experience before, but one time I was learning to, to get my local build set up so I could write some, So write some automat.

And to run it, it took me five days to get that first build going on, on my local machine because it was so convoluted and hard and at the end I just felt like I have created fire. But why should that be the experience that we have? Like it should be so easy. And what if we had a world in which your first line of code is delivered that first day that you join a company or join a team because we've made it so simple for you.

To just get that build up, deliver your first line, and, and, and push it to pride. Like how, how delightful of an experience would that be if you can see that you're adding value from day one instead of six or eight or 12 or even longer weeks later, you know, from that first time that you joined that team.

And I think when we can have those experiences, like from the ease of being able to do something to understanding to how we work and, and, and operate with a team. That just makes it so much happier, which matters on our wellbeing because we need that balance in life too. I mean, I've seen and I've experienced where I've brought a bad workday home and my kids notice, and I don't want that for them.

Right? I want it to be, even if we've had hard problems, we can do hard things. It's not saying that this is gonna be easy, but I am gonna make it an enjoyable environment in which to. And have that safety to fail and celebrate those failures versus feeling like I got yelled at because I miss something as a tester and it made it into production rate.

I've been yelled at. It, it hurts and you take that and you internalize it, and it might affect how you approach something again in the future or what to raise a risk in the future. And we need that for our own psychological wellbeing to be able to, to have that effective experience and become more productive over time.

Yeah. Yeah,

[00:13:44] Michaela: definitely. I think there are a couple of things that really resonate with me. So there are two things that you know, are quite different than I want to discuss. One is, Yeah. That you were talking about factors, Right. And I also describe factors in the paper. Mm-hmm. And some of those are technical, right?

So for example, the CI pipeline or maybe also having this build go through, having you, this image set up. You can run actually the software, this is more a technical problem, but on the other hand, we also have the culture problem, which, you know, they're always fading into each other because if, you know, if the build doesn't really work, maybe can you reach out to another person?

Will, you know somebody sit at your desk and help you? You know? Or will you get, you know, strange looks and maybe somebody comes over and say, Yeah, do this event is gone. And then you feel bad asking them again. Right. . So . Yeah, exactly right. So there. Technical and the social aspect of it. And I think, oh yeah, those are really important.

What's your, what's your experience with that?

[00:14:45] Ashley: Yes, so, so critical. I think if we don't have learning behaviors, and by that I mean am I on a team that is willing to learn from each other? Be able to have the practices in place to know when we need to go learn something and help each other learn.

You probably have a variety of skill levels a variety of skill sets, you know, on your team, and so how can we leverage those from each other to build a cohesive unit as a working group and learn from each other? You have to have some social elements that you're taking account for. If I can't ask for help, I'm going to flounder and fail in in my, in my world.

I remember my first time learning automation and I was getting stuck on writing some code for it. And you know, I think some of us have different drivers on do we feel comfortable asking for help? Do we need to be perfect? Do we just wanna please other people, right? Or do we just wanna get something done?

But. If we listen to those drivers in a world, let's say, I'm afraid to ask for help. I don't wanna ask for help cause I don't wanna appear weak. What am I going to learn? How am I going to become a part of that team? And when I can ask for, for help from somebody that helps create a social bond with that person that makes us want to be able to continue to work for and with each other.

And I think it's so critical that we create those, those relationships as well to help improve that experience. Yeah,

[00:16:21] Michaela: so my question is also, Blackboard was a large organization, right? Or Yeah. Yeah. And now Tech Li o is smaller. You said what? What's

[00:16:32] Ashley: smaller? Yes. What's smaller? So the company itself is 300.

So Blackboard by the time I left, I was around 3000 people. Yeah. Okay. I go to tackle io 300 people total. So I went from an engineering department that was around 1200 to an engineering department that is right around 90 people right now. Okay. And that's what I actually, I love it. I didn't know what to expect.

But what I'm finding is I have the time and the bandwidth to build a relationship with each person in engineering right now. Mm-hmm. . So my goal is to actually have a one-on-one with every single person in our department, which was not feasible at my last company, . Yeah. You will at least have met me, by the time we hit the end of October.

So I finished my first quarter. My goal was to meet every single person engineering. But I love that because what it lets me do is create that, that touchpoint, that human connection with somebody, because not many people wanna just open up immediately and say, Here's all the things that would help my experience, Right?

I don't jump in and say, Tell me all the things that are wrong so that we can go after and fix. I will eventually, but how do I create that trust? To me, it's more important to build that relationship, build the trust, so that when I do ask you, you know, I'm coming from a place of honesty and good intent.

And really it's not about complaining. It's about what can I do to make your experience better, and how do you know that I'm the person that cares so deeply about. That you will trust me to help make this happen. And so that's really what I'm after. It's, it's kind of amazing in a way. So yeah,

[00:18:12] Michaela: so we have this 300 and the 3000, and then there are companies in the size of three, right?

Yeah. And I actually worked with, you know, a big range from them. Yep. Even at larger corporations. Right. With hundred thousand people, but. . I wonder sometimes, right, with, let's say Microsoft, for example, is really large organization and, and they have like their own department for developer experience, I mean mm-hmm.

wasn't called developer experience, but it was, I was in this team, it was called Tools for software engineer team, or one ES one engineering systems team. So, but the focus is making engineering better for the internal developers, right? Mm-hmm. , it's a large endeavor because there are like 100,000 people and a large portion of that, let's say 40 or 50,000 R engineers, right?

So mm-hmm. , but then you have like, as you. 3,303. And lately have a lot of experience with smaller companies, right? Let's say 20, let's say three, maybe 5, 10, 100. And what I also see is that especially the startups, They also don't value developer experience, , , you know, like then, then we are so small and everything is just a hustle and the grind.

That there is no place for developer experience. I don't know if there is place for heart. Yeah. Later on, you know? And, and, and I always feel like if you can't, you know, if you can't focus on developer experience, if you're a three person team, or not only developer, even employee, you know? Mm-hmm.

experience. If you are a three person startup or a five person startup, and you know, all those are after thoughts because now we have, you know Yeah. To get to the market and make money and, and, and, and, and later on we will think about, you know, how people. Mm-hmm. ,

[00:20:01] Ashley: I think what I like, this will not work.

It's interesting because, so tackle's my first startup and I was really, really intentional when I started you know, thinking about what is next on my journey. Mm-hmm. on a company that has, has proven that they value the employee experience. Mm-hmm. , and I'm not taking, you know, just engineering, but what impressed me about tackle is.

From the start, they cared about wellbeing. It is in their values that they established as a beginning, at the beginning stages of their company. That, you know, we care about each other. That we worry about our wellbeing and our leadership reflects these values. And you know, if they see it not happening and they still do, tap me on the shoulder, say, Ashley, I saw you are on Slack sending a message at midnight.

Why? Please don't do that. Or I thought you said you were on vacation. Why are you responding to a message? Things that I don't know that I ex I expected when I joined, but deeply appreciate that it is so ingrained in their culture to care about the experience and our wellbeing. So I was, I feel really fortunate to land where I did.

But what I love is that, you know, they're about, we were on, on series Cs, so, you know, not, not super early for tackle. Not quite late stage yet, and. They saw the need as they scale and grow their department to worry about the developer experience and care deeply about it enough to create a new program.

Mm-hmm. . So I was super excited, that, you know, I was selected to come in and help establish this program where, yeah, you don't hear about it too often in the small startup space. Because yeah, you gotta get, you gotta prove out your. Your value, right? You wanna make sure that you're hitting the market need as a early startup, you know?

But how do we do that in a way that gives, it focuses on the care and feeding of our engineers who are going, who are, It's very easy to dive into just. Go work all day only and deliver this thing because we need to do this. Right? Yeah. But I love that, that that is not necessarily the case here.

[00:22:16] Michaela: Yeah.

Thankfully have forgotten a name of the company because otherwise, you know, I name in Shame, which I'm not the person for. I don't like naming. No, I don't. But anyway, No, I don't like that. So I have forgotten the name, , but there was a Twitter thread and, And this guy was, You know, come it work for me. We are like really hard problems.

Really low pay . Yeah. You work all day? No, actually he didn't say low pay. I think he said. Competitive. So competitive vape, but you work, you know, day at night and evenings and whatnot. Right. Yeah. And, and if you like, free time, don't work for me and so on. Right. It was longest read and, and I, I read through it and I think it was meant a little bit sarcastic or fun, nor, I don't know exactly.

But yeah, it was this, this hustle culture thing, Right. And I thought like, wow, I don't know.

[00:23:05] Ashley: Yeah. It's how that like puts us off too, right? Yeah. Like if I read like incredibly passionate about delivering everything, it's like, of course I'm passionate. I wouldn't be applying if I weren't passionate about my role.

However, Yeah. I internalize that. as, I need you to work all day and all night on this problem until it's out the door. Like, yeah, it's a, I'm just not, I'm too one. I'm too old for that. Two, I like to spend time with my family and my kids like, yeah, if I see something like that on a job posting or hear it described like that, it kind of turns me off in a little bit.

Like, yeah, why am I not expected to have balance? Yeah. It was

[00:23:43] Michaela: really like, if. Work life balance for you means to have a lot of free time. This is not for you, right, . I'm like, well, what else

[00:23:53] Ashley: should it mean? This is about the biggest red flag I ever heard. Yeah, Yeah.

[00:23:57] Michaela: But but, but, but I wasn, but I'm wondering.

Right. And it was all under this umbrella of all we startup, right? And, and so you have to be super passionate about, and so but I wonder if you can get rid this DNA or if you can strive it off at one point, Right? If could say, Oh, now we are this 10 person and we don't make it enough revenue. And so we hired all these people that have this mindset of, you know, Working day at night and, and whatnot.

Mm-hmm. and so on. And then at one point we transform into this developer friendly, employee friendly entity. I, I, I can't imagine, Right?

[00:24:32] Ashley: I, I, yeah. I think it's possible. I think you have to assess, you know, there's, there's things that you can look at. If I put on my organizational psychology hat, right, , you can look at the current culture mm-hmm.

And what it is, and you can look at desired culture. Mm-hmm. and it, it could take a very heavy lift and a lot of time to get to that desired culture. But I think it's feasible if you understand where you're starting from, where the desired end state is, and then start putting an action plan in place to get there.

So let's say you are in a sales driven culture, right? Yeah. Sale, sell, sell. And it basically informs what your engineering backlog is. It's kind of a dangerous and scary spot to be as well, because what if they, they sell something that you haven't yet built and they promise it to somebody. That's a really high stress environment, right?

But what if you want to move to a more collaborative and generative environment or culture? Okay, cool. How do we now set the the things in place with sales, communicate to them, This is how we wanna start doing things. and then start working with them. Well, what, how, how can we do this? Right? How can we meet in the middle so that you're still able to sell something?

Because of course they have targets at the end of the day. But how can we get to a place that is healthy for everybody? Maybe let's sell what's there, not what is in the future. Something can always go wrong, right? And what are the steps we need to take as an organization to support that and start transitioning to a more collaborative and communicative culture.

From that, or maybe you have a very hierarchical driven culture. Everything is top down. It's very bureaucratic. I think that you can also set in place the ways to move along this dimension of, of what is more collaborative in nature, more organic feeling than a very, I like to call it the, like 1990s, early two thousands management style.

But I've seen us transform. It took years, but we've done it right. Like I had no problem at Blackboard at the time talking to the CEO if I just wanted to talk about something with him. Whereas earlier in my career, it was very, very difficult to get that call with the CEO to just have a chat or something.

You know? It just depends on what that. Yeah,

[00:26:50] Michaela: maybe there's a, a German saying, I don't think maybe you can tell me if there's a English version of it. I just translated literally so it, it doesn't sound very nice, but , the fish starts to think at the head. , Do you have something like this? ? I don't think

[00:27:10] Ashley: we

[00:27:10] Michaela: do , but what it means is that leadership somehow sets the stage, right?

Oh yeah. For the company and for the culture. And, and so what you describe is, Yeah. Is so I, I've seen two. Right? When I joined Microsoft, it was still Bama. Yeah. And it was an extreme different culture and organization you know, than you know, when it changed and, and it was transformative, right?

[00:27:38] Ashley: Yeah. I was, It takes adaptive leadership to be able to drive that type of change. It takes transformative leadership. Yeah. I would say the closest that, that I think I've heard, Well, it was funny, I was just watching, remember The Titans with my children last night? Yeah. I don't know if you've seen that.

But it's about a team that comes together you know, at, in a point of United States history where we're, we're integrating schools and a football team forms. And one of the saying that always sticks out to me is attitude reflects leadership. Mm-hmm. , And I always take that with me because as a leader, my, my own attitude is going to be mirrored back to me from the people that work with me or for.

And I always try to make sure that I am leading in a way that I can stand by and that I want my team to, to. You know that they have the best attitude and ability to move forward. But yeah, you, you have to have to make that change. It, it's leadership style, right? Yeah. You, you have to be able to work with others and collaborate.

Rarely is it gonna be a top down decision making driven thing that's gonna drive change. It's gotta come bottom up. It's gotta come top down and sideways to be able to communicate all the things and work together. , you have to have a clear vision. You have to be able to, to guide. You might not have all the answers as that leader, but you sure can ask questions to get there,

Yeah. And help the team through that and navigate through that change cuz ch change, like I said, it can be a change for the better. But it is hard, , whatever we deal. Yeah. It's

[00:29:07] Michaela: extremely hard. Yeah, that's true. I mean, I'm working with people on culture views, right? So very focused. At Microsoft I worked at many different aspects of developer experience, like the, the, the cycle testing and so on.

For my workshops right now, I'm really focusing on culture views. Mm-hmm. And so it's, it's one area. And in my workshop we are going to. Code reviews, right? And the code review processes that people have and thinking about, you know, how can we make the experience better and. and it's hard, right? Yeah.

Even though it's a small thing, you know? Yeah. You would say, well, you know, it, it's even at the fingertips of developers. But still, it's really hard because it's a team practice, right? It is. So you have to have more people on the team really be willing and committed to make the change. But then if they do it, if they are committed, I mean, it, it takes wonders, right?

It, it, it's really different experience. It's, yeah, it's

[00:30:00] Ashley: huge. It's, it's not, and it's not just the, the timing of the code review. Cause I've also, you know, part of the experience is how fast am I getting my feedback? Yeah. So that I can make the changes I need to, and, you know, get it through, it's what is said in these code reviews.

Yeah. I remember I like, I was so blocked when I was first learning, I got one of the meanest comments ever , like on a code review. Somebody I guess didn't realize it. It was like one of my first prs and just like, Why would you do it this way? And I can't believe what I was like, Okay, I think I'm just gonna not automate anything ever again or write code ever again.

It's fine. . Yeah. So you have to think about the experience there, right? Like. What is that, that holistic view, not just the timing and how many people are able to do a code review, but what is the content? What is the meaning behind it? Are you actually teaching and coming from a place of learning and growth versus maybe we had a bad day kind of getting snippy with people, or I just wanna get through this code review because I have a lot on my.

It just depends. Right? But I think you need to take that whole view. Yeah. Of what is that, that whole experience. And

[00:31:09] Michaela: I actually like culture views so much because very similar to, you know, developer experience. I would say the developer experience is like the big umbrella, right? Mm-hmm. . And then culture views is one aspect of it, but it's an interesting aspect because it has.

It's a technical sociotechnical engineering practice, right? So you have the social aspects, you have the technical aspects, so you have to be technical words as well. And then you all have as the third organizational aspect. So in this little practice, you actually have all three. Most important skill sets in there.

Oh yeah. Right. And I think this is what makes it so fascinating. Yeah. So I want to come back a little bit to the paper that I wrote with Avi Notre and Margaret and story. Right. It's called, How is it called? Let me see. To level an actually framework for developer for improving and understanding developer experience, Right?

I think this was the title that we settled on. And so the paper is really, so we made an in depth study really on what's important for developers, what's impacting their experience, right? For the good and for the bad. And so we made the list of several factors. So this was a qualitative study. So a couple of themes.

We did interviews, a couple of themes emerged, right? And some of them were really the factors. But then it was also what's hindering developer experience. How do people compensate, you know, their negative experience and so on. And you, you read the paper, what, you know, what was interesting for you and was there something in it that you could actually take And You know, and apply maybe in your job.

Yeah. As developer experience director.

[00:32:47] Ashley: Yeah. It's, it's, it's when I came across the paper so how I was approached my job was can you take the things that you were learning from organizational psychology and apply them to engineering? That's, Yes I can. Let's talk . And so I do, you know, I try to do a little bit of research each morning, what's going on in the field, what are people other people finding?

Cuz it's still fairly new-ish compared to other topics in our field. Right. And when I came across the research paper, I was so excited on a few fronts. One. That okay for you? Yes, I am new to like doing research and graduate level work, but I was really happy that my methods are very similarly aligned with your research methods.

Granted it's within my company, but very, But you know, let's have the qualitative interviews. Let's understand. Let's find the themes. I had started theming my things out. Mm-hmm. then I was really happy that my themes were aligning with the themes that you also had been outlining. That's. You know, different words, but ultimately very similar structure.

Things that we're, we're looking at and hearing from people. But what really fascinated me and what I loved is that holistically looking at the paper, , all of these aligned to things in, in organizational psychology. From where do we find fulfillment and job satisfaction? You know, the importance of having clarity in our goals how we work with product.

Sure. We're not gonna be talking about how do we work with product managers and organizational psychology, but we are gonna talk about how do we understand our significance? Where do we fit in this universe? Do we understand how we provide value? Do we understand the positive impact we have? Are we able to work iteratively?

Are we able to do feedback loops? Everything in software development in the world of psychology is an I P O model or input process. Output model that is just super cyclical. That's all we, I look at these diagrams all day long. That's DevOps, That's testing, that's like software development life cycle, right?

Thinking about our tooling when we look at your development and release theme, right? All of those questions we look at the environment, the health of my code, how confident am I all of those things come down to our experiences that we can generalize into. Or if I like to think I like how can I apply it into organizational psychology terms?

Cause I like to write about it in, in my classes. But I was so excited to think, okay, I think I feel like I am home. I'm studying the thing I'm passionate about. I feel like I'm a scientist, practitioner can go forth and do these things. I even like, how do we notice when people aren't feeling these things?

How do we notice when people are having a bad experience? I thought that was such a critical part of the paper that's not often talked about. I think, you know, we, we all say, Oh yeah, we should do this based on my experience. But what I really enjoyed was reading, you know, What are the, what are those implications?

What should we look for as leaders? How might people be coping if in the absence of these factors? And those should start to give us some, some red flags there if we're not careful, what we might lose people or worse, not be able to revalue at the end of the day. Yeah. I mean, worse to me is losing people and having somebody have a horrible experience and, and be turned off from tech because I almost quit tech.

Right. I don't wanna lose that, but are we going to be able to meet organizational goals without looking at developer experience? I'm not convinced we can. Because we're building the thing the organization exists to deliver. And if we don't focus on that experience, you know, what are the implications not just for our teams and the people, but for the company as a whole?

And, and your paper is just so, so good, and I can't wait to dive in more for further research on my own, even if it's within my teams. But I, I. I just think it's such an opportunity for growth for us to discuss as a community, for us to think about not just what are our personal experiences, but what does science and psych and psychology and organizational psychological research tell us?

That can be applied here too, for even deeper interventions. And in looking at that,

[00:36:47] Michaela: yeah, this sounds really inspirational. So one of the, the last questions that I have for you is for my listeners, if they want to improve developer experience and. Companies, what would you suggest them? What's, you know, what are some of the things that we should tackle first?

Is there some factors that are more important than others? Is there something that you can say in general, you know, this is a good, you know, this is a good investment Yeah. Of your time and money.

[00:37:16] Ashley: Yes. So I don't necessarily think you have to go have a separate developer experience program to be effective.

But I do think there are a few aspects. If you want to show quick wins, you know, what are the things that might be high pain points, low effort, and just start doing You know, I somebody once said, Be the change. You want to see , so how can I do that? , maybe it is, Oh, I need to talk to my team about psychological safety and, and run this workshop with them.

Maybe I want to make sure that we are clear on how we write stories so that my team has a clear understanding of what work they need to do and why, but also how do we go in and break that work? What are some short term wins that we can find to build trust that people see that we are effective to then get more and more complex over time.

And so I think, you know, some things are really hard and gnarly and take very spec specific skill sets to do and implement. Those are great, Put them on a roadmap, but think about what are the short, fastest things I can do that will be even a quick, easy win for my team, Make their lives easier, provide value at the end of the day and maybe not such a heavy lift on maybe one person.

And then maybe start to show more and more of those as you grow, and then be able to get the buy-in to build the team that can solely focus. .

[00:38:40] Michaela: Yeah. Yeah. Sometimes it's really hard to get the buy in. Right? So, so hard. . Yeah. . Is there something that you can recommend? Like how do we, how, how do we, you know, translate or make sure that other people not in engineering understand the value of developer experience?

What's your pitch? I mean, there's the, the metaphor for a technical depth, right? Where Yeah. Are we talking about that? To, you know how you, Nobody cares about that on Yeah, exactly. , but how. How can we, I think developer experience is even more complex, right? Because people at least care about the software.

So technically that even though it's hard, it's a hard sell, I think or hard sell. At least it's about the software developer experience is even about the people, right? It's even more. Fussy and so on. How? How can we make sure people understand the value of it? How would you explain it to management or to C level

[00:39:36] Ashley: that happy.

Happy engineers. Happy clients. Right. If you look, focus on the happiness and experience of your teams, at the end of the day, you should have happy clients because we are able to, The things that we think our clients value and see value in just ev all the more effectively. So I think if you can sum it down without having to talk about all the technical aspects.

Right. What would your slogan be? Mine is always, usually people first off or second. However, when I think about in terms of providing the value to sea level, happy engineers, happy developers, happy clients. Yeah. You know, it, it shows, right, the, there's this, there's a saying or analogy here in the us. A happy cow makes better milk

Oh yeah. Really? . If they're grazing, they're eating. You know, good food, they're ate, getting access to grass, the milk quality goes up. They're not stressed. It's funny how even or if you're a human, like think about the stress and the effect of stress on our bodies biologically. And physiologically, you can still maybe perform the actions you need to do, but at the end of the day, your, your blood pressure might be up.

If we don't have that, that stressors on our engineering teams think about the quality that they might be able to deliver in a sustainable way, in a way that makes them excited to stay at the company and want us to be there day in, day out, and excited to get up and go to work and work with their team.

I

[00:41:06] Michaela: don't think that there is a specific developer research exactly on this topic, but I know that there is quite a lot of employee research, right? Mm-hmm. So employee experience, which is a. , it's a topic on its own, and it's a little bit older than developer experience, right? Mm-hmm.

So we borrowed a lot ideas and concepts from, from that field actually. Mm-hmm. , and they show exactly that, right? They, they show with case studies and with different studies that companies that are valuing, right? The experience of their employees in general. Yeah, those can also value the customers and that they're much more successful doing that.

Yeah, so I will probably put some some of that in the show notes as well. So if people want to deep dive, they can.

[00:41:55] Ashley: Yeah. Yeah, yeah, yeah. It all, it all comes down to like, you know, science and research that's been done, you know, many years over. We're just looking at a specific application of it Exactly. In tech, and it's fascinating to see how you can, how it's been generalized for more fields than just our industry.

Right. But when we can take a look back, And see, Oh yeah, Oldham's job characteristics theory is actually super applicable to us. For example, like thinking about five dimensions of, of our jobs and what are the critical psychological states that emerge from being able to have positive experiences in those, those five characteristics.

And then what are the outputs that we see, right? Retention, higher value, happy client, all of these things, higher productivity. All the things we care about in, in engineering that you know, it's just amusing to me to reflect back and like, Oh my gosh, this, this research was done in the 80, 1980s, like yeah, so many years ago and still applies to what we do.

That's true and I love it. Yeah.

[00:42:57] Michaela: Yeah. Yeah. So, cool. Well, thank you so much Ashley, for, for sharing everything today with me and I will put everything that we talked about in the show notes and obviously thank you. We'll also link your, your profile. Is there something as a last message that you want to give to my listeners?

[00:43:17] Ashley: Oh, . Sure. Let's see. You know, it.

always put the people first. I think when in doubt, I've never seen it fail me as a leader. Yeah. Think about, you know, your wellbeing, your team's wellbeing. If you can put that first, I really feel like the rest will fall into place. And even though those other aspects might be really challenging, Because you come from a people first mindset, it makes it so much easier to tackle those challenges together.

Yeah.

[00:43:54] Michaela: That's a really good closing note, and I totally agree. So thank you, Ashley, for being on my show. It was really a pleasure talking to you.

[00:44:02] Ashley: Thanks for having me. Yeah, thank you so

[00:44:04] Michaela: much. Yeah, bye bye. Bye. Hi, 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 platform 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.

Episode source