Blog

Quality Sense Podcast: Ashley Hunsberger – Leading Agile Transformation at Blackboard

by April 7, 2021
DevOps Testing
0

This week’s Quality Sense guest has been at her company now for 16 years, but in that time she has had the chance to assume several different roles that allowed her to explore her interests, lead others, and help the company grow. Ashley Hunsberger started as a manual tester and today, she’s the Director of DevOps Engineering, creating their Developer and Agile Advocacy program. She focuses on the ways they can advance the work their teams are doing, as well as the way in which they do it. 

Listen to this fascinating conversation or read below to learn how she managed to evolve her career while staying with Blackboard over the years and ultimately came to leading agile transformation there. She offers eye-opening, real world insights on leadership that anyone can apply in their own organization.

Thank you for helping us to reach 10,000 listens of Quality Sense thus far! We’re grateful to everyone who has collaborated and joined the community.

Episode Highlights

  • The need for innovation, experimentation, and learning in a DevOps and agile culture and methods to promote them within your team
  • Fede and Ashley’s challenges in adopting OKRs and lessons learned
  • Psychological safety in the workplace and why its essential for leading agile transformation
  • How testers can safely innovate by testing out a series of hypotheses 
  • The benefits of practicing reflection to improve your ability to cope with change and find a way to do the work you love

Relevant Links:

Listen Here

Episode Transcript

Federico:

Hello, Ashley, how are you doing today?

Ashley:

Good. How are you doing?

Federico:

Fine. So excited to have you here on the show! Welcome.

Ashley:

Thank you so much for having me. I’ve been really looking forward to this all week.

Federico:

Amazing. My first question is something that really caught my eye, checking your LinkedIn profile, which is, you’ve been in the same company for a little bit longer than the average in our industry, right?

Ashley:

I know. That’s true. I started at Blackboard in 2005.

Federico:

Wow!

Ashley:

So it’s almost 16 years in July. If you go by United States standards, I would be getting my driver’s license this year at Blackboard.

Federico:

Okay. This is a good way to measure it!

Ashley:

Yeah, but it’s interesting because I think a lot of people, you see around three to five years in the industry average. But it’s not like I’ve had the same job. I mean, I have been in testing for a long time. But it’s not the only job I’ve held here nor today. So yeah, I started as a tester and back then it was very waterfall, very manual. I would say that the main career path that testers saw for themselves and myself included back then was “Alright, I’m a tester, okay, maybe I’m a senior tester. Maybe I’m a test lead, and then manager.” And that was what we saw, what we knew in the field, but it’s very limiting, right?

So it’s been interesting. Yeah, I did progress through that. I started on a few features in one of our main products, through acquisitions, as we built out more and more products as well. I remained with our core product through most of my testing career until I became a test lead, where I still focus on several features in that area, but leading a lot of people through testing and working with engineers and teaching them about testing.

But there came a point where beyond that, it was like, “All right, I can wait for my manager to quit and maybe I’ll become the next manager, but is that what I want or what?” 

“And what I loved about Blackboard, and I would say this to anybody, is you’re not restricted to this management career track. It’s not the only path for testers, I was able to take a look at what we needed as a company, and what we needed at our products, and really kind of fill the gaps with what interested me, which was strategy, designing how we want testing where we want it and how we envisioned it for the future.”

ASHLEY HUNSBERGER

And that really led to my role as a test architect to start and that brought me into looking more at our automation that we are trying to get going for a third or fourth time, and how can we be successful? And that got me thinking, all right, where do we want testing? And if we say we want continuous delivery, how does testing fit in there? And so my job was designing, where do we want feedback in our pipelines? And it wasn’t that I was going to go build and automate all these things. But I also became a technical product owner. So partnering with our automation engineers, and our CICD team members, how can we build our pipelines out? How can we add testing into the pipelines when we want it? Why do we want it there?

And so that was my job for a couple of years. And then we had an opportunity to look at how we’re building software in general, and took a step back and said, “Okay,” a lot of companies took a look at this, right? It’s not just Blackboard. 

Do we want this big monolithic application? Or do we want to start looking at a micro service oriented architecture? And there was an opportunity, given my work with testing and automation and CICD, to then lead a release engineering team. And that’s when I became director of DevOps engineering.

There’s several of us, but my focus was release engineering at the time, and working with a team that had started to set out building a paved road of sorts. So if a feature or product team wants to create something now as a micro service, they no longer have to now go learn how to build a microservice. We could provide them the toolset and infrastructure to spin this up and then build out on top of that.

So our team remained the experts and really in an inner source way, how can anybody contribute? And that was where my focus was in release engineering on top of accessibility, localization, and really keeping that DevOps mindset and culture within those teams.

Then, last year we had a bit of a pivot. So as organizations do, they look at, “How are we set up? And are we organized in the most effective way?” And part of that pivot came with a change in my role alongside the way that we’re architected. We also started to look at “Okay, we really need a serious look at how we’re building software” and so is it also enough to say, “Okay we have scrum, we’re still a little bit waterfall,” so we really started to look at an agile transformation as a company and so that kind of became three words that our CPO said was, “I need you to lead our agile transformation.” 

That’s way more than three words but that was what I had to go off of, but my interests are still in DevOps culture and mindset. So I had another opportunity which I feel is just kind of weird, I’ve had three opportunities now, at the least, to define my role and create it but I got to look at “What do I value? What does the company need and how can I kind of align those together?” 

And so what I got to do was create a whole new role as part of being a Director of DevOps Engineering to really focus on the culture and the people and so now I’m really leading developer and agile advocacy at Blackboard, where most people might think of developer advocacy as external, I focus on the internal.

And so I look at, all right, what are you building? How can I help you advocate for that? And what do you need to be successful there and be effective? At the same time also, mirroring that to our work in leading agile transformation and “How does what you’re doing align with what we need to do and go for it as a company? And how can we help you do that in a way that can translate to everybody?”

And so really influencing the way in which we build software at a very, I wouldn’t say abstract, but more the strategic level than the, “This is how we go and build a micro service, this is the infrastructure you need.” Now we’re talking about the hard part, the people, the culture and it’s my jam, I love people.

“My underlying guiding principle is people first, software second. I just really believe if you focus on the teams, the people; building those effective teams, the software is going to come, it will happen and we just need to get those practices in there that let us do that.”

ASHLEY HUNSBERGER

Federico:

Yeah, to enable the people to build the software in the best way they can, right?

Ashley:

Yeah, so long story short yes I’ve been there forever but it feels like I’ve had a few different careers in my time, I haven’t just been a tester on the same product for 16 years. 

It’s great when you can find a place that lets you experiment in not just the work you do but your role and try something new and if it doesn’t work out, let’s pivot, let’s see what else we need and find those gaps. I mean, that’s a huge business value to be able to do that.

Federico:

I think there are two things that are really key in what you mentioned, one is that the company grew and you had the opportunity to grow along with the company, right?

Ashley:

Mm-hmm (affirmative).

Federico:

So as the company evolved there were more opportunities and needs and this is something that typically happens mainly in small companies when they are growing, I guess that you had the opportunity to see the company growing and transition in all those different stages, right?

Ashley:

Yeah absolutely it’s important, it’s not something I thought of early in my career necessarily, but the more I’ve progressed to have that economic view of the company and to be able to step back and see, okay what’s going on? Are we trying to scale? Are we trying to simplify? You might see different phases of a company, I’ve seen us acquire a lot, I’ve seen us divest a lot, it just depends on what is the need? Why are we doing that? What do I need to do in relation to that or what are we missing that maybe I can help with.

And so being able to get that view is super beneficial as any member of a team, but I think it’s interesting because I think testers are so well suited to do that. We often look at not just the granular thing of what we need to do but we have this incredible skill set to step back and get that 30,000 foot view and maybe it’s not a product but look at the company in that way too. We have that skillset as testers to do this.

Federico:

Yeah, maybe analyzing their business and our perspective, trying to think in their [crosstalk 00:10:10] and what can go wrong? Right?

Ashley:

Yeah, we are risk communicators at the heart of it and feedback givers, though you don’t just test software, you test ideas from a feature idea to an idea that a colleague might have on a process improvement. 

That’s what we do, we test things.

Federico:

Yeah. And this is something that we typically need at different levels of any company. So, for example, I have an example related to that, is that this is the first year at Abstracta, we are implementing OKRs.

Ashley:

Yeah, we’re doing that too. Okay.

Federico:

And I tried to involve as many testers as possible, not only the C-suite or the managers. But also the testers because they are willing to provide feedback for anything, and it’s really valuable, so absolutely.

Ashley:

Yeah, how’s that going? I find OKRs very hard to write.

Federico:

Yeah. Same experience. And also, we are trying to focus even more, because at the beginning, when you think, “Okay, this is going to be the year and we want to achieve this and this.” Okay, maybe in the following quarter, one of the main things is to reduce the scope and be realistic. But this is something that we need to learn. It’s part of the process, I guess.

Ashley:

It’s a good exercise. I think the hardest part for me was realizing it’s actually okay to not hit 100%, let’s hit 70% and even then it’s hard. And it’s gotten me into a better practice, like, “Oh, I probably shouldn’t have nine individual OKRs. This is not going to happen.” Maybe three is my sweet spot for a quarter where I’m still stretching myself, but it’s hard. Yeah.

Federico:

Yeah. Learning about that, it’s part of the process for sure.

Ashley:

Yeah.

Federico:

And the other thing I wanted to highlight regarding Blackboard and your story in the company, is that, for sure, and I’m pretty sure that the company also values the same thing that you mentioned about the people. Because someone saw in you the potential, and they work with you in building the possibilities.

Ashley:

Yes.

Federico:

That’s also key, I can imagine.

Ashley:

They invest in me, which really, it’s what keeps us around. You can always have a cool shiny thing you’re working on, but when you get a company that says, “Oh, there’s potential there, let’s send her to adopt a leadership cohort,” where they put you in a room for five days, once a month and you’re learning from some of the greatest minds I’ve ever seen in the company. And working with organizational psychologists, and learning how to deal through change and lead through change, and how to work on integrated teams. They’re teaching you these skillsets, it’s no longer, “I need to go read this book on my own and apply it,” which does happen a lot.

But they’re saying we’re going to give you the tools and the training and the people and the network with people I would have never thought to have reached out to or even knew existed, but they help you build that and it’s been pretty amazing that we had that opportunity.

Federico:

Amazing. Tell me more about the transformation for the DevOps and agile culture. You were telling me the other day that enabling people to learn and to experiment, it’s been an important part of that.

Ashley:

It has, it’s critical. The key concepts of DevOps culture already are flow, feedback, continuous learning. Layer that with agile, and how are we doing this in small incremental ways that we can deliver value faster? But at the heart of it all, as I reflect on the last year, especially, is this critical element of psychological safety.

And for those that don’t know what that is, ask yourself, are you afraid to raise issues? Or take risks or ask for help or disagree with your teammates? Or make mistakes or be yourself? Or say, “I don’t know something.” And the critical thing there is yet, right? But all of that is at the heart of innovation and experimentation, which feeds into that DevOps and agile mindset that we need to be able to have. 

We need to be able to raise those issues. We need to be able to take risks, we need to be able to make mistakes and to learn from them that’s what drives continuous learning and improvement.

And so as we think about flow and feedback, what is that flow of information I need? You don’t have to just think about how does my code flow through the system but how does information flow upwards, sideways, downwards through the organization and how do we get that feedback we need, if it’s just an idea, don’t think about just the automated tests I need but what feedback do I have on an idea to know if it’s a good one or should we proceed, are we building the right thing? All of that integrates into that and without that psychological safety and that ability to raise issues, I don’t know how you’re going to have an effective team and be able to adopt those mindsets at the end of the day.

So it’s critical, like I said it’s not just the idea, it’s the exploration that comes with it, the ability and the skillset to design those small experiments. Because isn’t that what we do all the time? If we say we have a story, we think we have an idea that will provide some value to somebody and here’s how they might use it. Great, let’s develop a hypothesis, let’s develop an experiment, let’s build it out, do it small so that we can pivot and learn from that if it’s not the right thing, great we’ve learned from failure. That’s a thing to celebrate.

Federico:

I totally agree. I would like to reach that point, but the problem is if I’m not there with my team, what can I do to improve, to go towards this mentality in the team?

Ashley:

That’s a really good question, it’s a hard one. I think the first thing is understand where you’re at. If you can’t make a mistake, why is that? Ask yourselves why? Get to that root cause. 

If you feel like it’s hard to raise an issue, okay, why is it hard to raise issues? What can we learn from this? So start actually getting into the root causes of the dimensions that you need to be effective. If you don’t have it, that’s okay every team starts somewhere different. But it’s important to build that time to work on the team not just, we call it on the team or in the team. On the team are the things that help you become a strong team. In the team is like, “Okay I’m in my backlog, I’m doing the work that we have to do just like really taking that narrow viewpoint of what is the thing I have to get done today.”

So building that space to be open, creating a safe space as a leader, super critical. If you find that difficult, maybe you find somebody that can help facilitate those conversations. I’ve been brought in to lead sessions with teams for example to explore that, “What is safety? What do we need? Where are we as a team?” 

Understanding that degree and seeing where we might have variants and in an anonymous way to help people still feel safe to share but then understanding, if we see maybe we’re not comfortable raising issues, let’s dive deeper, what’s causing that? What can we do in the next few weeks or the immediate future to maybe solve one part there. But what might we need to do longer term to help build that safety net for the team.

And so really focusing on those dimensions I found to really be critical to get there and it also helps to know a little bit tangentially related to that is the ability to navigate and manage and lead through change. 

“Even if we don’t talk about psychological safety, our brains are hardwired to view change as a threat.”

ASHLEY HUNSBERGER

And so what happens when we see a change? It can be something innocuous like a desk move or maybe during the pandemic you were told you’re now going to be remote forever, maybe you have an organizational change, maybe you have a new team member, that’s a change.

So we see this as a threat and what happens? We have a flight or a fight response. And so how do we navigate that? How do we lead through that? And you don’t have to be a manager to help live through that. You can be a very just in touch team member that’s aware of the body language, that’s aware of listening and what’s going on, what’s not being said. Asking open questions to get people into a sharing mindset so that they kind of come out of this amygdala hijack and can start putting words to their feelings.

That’s also a critical thing, any transformation we have, that’s change. And so how do we help lead people through that and navigate those waters, because it is hard. A lot of the work, I mean, 20 plus years in tech and it’s really coming down to, how do people respond to change? How do people respond to each other? What are the psychological impacts and how do we build those effective teams all through focusing on that.

Federico:

Wow, that’s a lot to process.

Ashley:

Sorry, I know it’s a lot.

Federico:

Yeah. I was also thinking that in order to improve this in a team, I think you also have to work on yourself. Right?

Ashley:

You do. Yeah.

Federico:

How you deal with change. How you feel about change.

Ashley:

Yeah. It’s not just learning as a team, “What went well, this sprint. What didn’t go well, what should we change to move forward?” It’s looking at yourself, “Are we making space to learn? Are we setting aside that time?” I think it’s very easy for businesses to say, “Oh, you can go read that book on your own time, you can go take that course, in your off hours.”

I don’t think that’s the right way. I mean, learning is part of your culture. How are you making that space to do it? And not just the retrospectives from the sprints. Which are still super critical, don’t get me wrong. But as we pick up new skills, say we have a new technology we need to learn great, how are we supporting that?

Federico:

That’s only a two hour meeting every week.

Ashley:

Yeah, it’s a constant learning process. For me, I do it every day, I set aside 30 minutes, even if it’s just my morning coffee to learn something, or read a chapter that maybe I haven’t been able to get to. And from there, I’m like, “Okay, great,” not just what did I read? How can I apply it today? And then it just helps me do that, and build that learning practice for myself.

I even hold retrospectives for myself, not just with my teams, but what’s working? What’s not? What do I need to change gears on? And that’s a good learning practice in itself, too, right? I think my favorite thing I saw recently, and we’ve talked about OKRs, my colleagues set up an objective and key results so that his team is actively learning, they’re setting an objective to learn new things and share that learning with the group.

So it becomes part of the work that they do, they are being measured on how many hours of learning? What new things are they learning? How many different things are they bringing in, to be able to share with each other? And even though we always struggle with how we word it, I love that he’s making it forefront and super important that it’s an OKR for his team, to know, “I should be building this into my day, I don’t need to go do this in my evening time that I want to spend with my family or on weekends.” It’s not a personal time thing anymore, which I love that we are seeing that happen.

Federico:

Yeah, and we had a discussion around an OKR associated with learning. And at the beginning, the way we addressed it was in the number of workshops or courses that you take or something like this. But the important part if we try to think about the key result, how you apply anything you have learned. So this is another way to see it and I think it’s really important because it also drives which courses or which activities or which things you are learning.

Ashley:

Absolutely.

Federico:

So, do you have any particular activity to do with the group, with your team, in order to foster innovation or learning?

Ashley:

Yeah, well, we’ve talked a lot about the importance of experimentation. So I’m doing my own experiments today. 

So I think historically, every other year, we set a few days aside as a hackathon. And those are great, that gives you a chance to really think about what do we want to build, or whether it’s a product or a technology we use as a team. But as I’ve reflected on that over the years, and what’s made me kind of feel not so comfortable with it is it’s really geared towards coders. And the people that can actually go and build those things. Now, I work in shared services, where we have a mix of people that focus on process, that focus on technology, that focus on coding.

So we have a huge mix of people and skill sets, which is amazing. But if we were to say, “Okay, we’re going to have a hackathon,” we’d maybe see five people participate, that felt like they had both the time and the skillset to do that and build something at the end of the week. So what we are experimenting with in our department is this idea of innovation days. So it’s no longer just this one, maybe two days set aside once a year. But we’ve built it into our quarter, so every other Friday, so every two weeks, we give people the space. It’s not mandatory, but we give them all day Friday.

And we say, “Use this time, as you see fit,” maybe it’s an hour, maybe it’s all eight hours, but you have the space to contribute and participate. And what we were looking for is… We’re not looking for a complete, finished shiny product, project or prototype at the end of the day or at the end of the quarter, but we are looking for an idea. And we’re looking at what can we improve upon, whether it’s process, whether it’s cultural, whether it is a technology we use, or whether it’s a product idea. 

And we’ve seen some really cool things come out of it. I think my favorite one was somebody created automated timesheets, so I no longer have to go in and manually fill out my timesheet anymore. I can see here this and it just deals with Oracle in ways that I don’t have to anymore. And it makes me so happy.

We’ve seen ideas for improving culture, for example, how do we onboard new employees, especially when a lot of our managers are maybe in the United States, but we’re onboarding people in another country. How do we do that in a remote world where nobody’s in the office right now and still make them feel part of a team, and learn what you need to learn about the company. And so we actually made the space to think about that.

We’ve seen other innovations or ideas come in on saving time, and even if it’s just calling attention to tools that we didn’t know that we had, showing how we can use them and what we can learn from them, which helps us evaluate our own time. And I think it’s helped me realize, I’m spending a lot of time in meetings, but not really sure why. Or, I’m spending a lot of time collaborating. I’m not getting a lot of time to be heads down and work. How can I look at those metrics that are automatically pulled for me now, and review my next week?

So we’re seeing impacts on ways that give us more autonomy over our own selves and it’s really cool to see this happen. So that’s really the main thing that we’ve been introducing. We started that in Q4, so the last part of 2020. And we’re doing that again in 2021, for Q1. And what we change this time from our learning, because everything is always meant to be improved upon in my mind. 

We actually added in other sessions, so not just, “You have this space, go forth and innovate,” but what skills might we want to learn about it? So how do we brainstorm? There’s different models out there, maybe you want a lean Canvas style to think through the business problem that you’re trying to solve for.

Maybe you want to learn about the scamper model where you look at, what am I trying to substitute for or combine, maybe you’re combining features of something, maybe you’re adapting something, maybe you want to modify it and tweak it or put it to another use. Maybe you want to get rid of something because you don’t think it’s worthwhile anymore. Or maybe you went to reverse something else, because the change wasn’t good. 

So thinking through different mechanisms, and different ways of thinking, even the innovation process itself. All of this takes practice. It’s not a skill set, you learn in 30 minutes, and then poof, no we do this actively.

I think the other thing we did, that we introduced this quarter, was the workshop on how to write a hypothesis statement. And so we introduced different templates, some very simplified, some a little bit more scientific method that we’ve maybe learned at university or in science class. But really actively getting at what is it that we’re trying to solve? What do we think it will get us? And how do we know we’re successful? And by when? Not just, how did we timebox it? What are the metrics that we think we’re going to look for? Because that’s how we make decisions if we want to be a data driven decision company.

We need to know the data behind it. So how do we know we’re successful and thinking through the success metrics? But also making it and, again, it comes back to that safety. It’s okay to not be successful. But we know by measurement, “How do we know we aren’t? And when do we need to pivot?” In setting up quick, small experiments so that we learn quickly instead of waiting an entire year, for example. And then finding out “Oh, that’s not hitting the mark.”

Federico:

Do you have any specific examples around testing? Because I know that innovation is typically associated with designers, engineers. How about testing, how can a tester innovate?

Ashley:

So I’ll just speak to my experience back for a few years. It’s a stuff that old hat, try to remember. So when I was a product owner, it was very easy to say, “Okay, we want all of this testing and all of these places in the pipeline.,” You can’t do that, it’s overwhelming to think about that big view and try to say, now go forth and make this happen right now. So what did we do? 

We broke it into small little experiments, we said, “Okay, what is the most value we’re going to see the fastest? Is it around our unit testing? What other testing do we want? And at what point?” And so we did the smallest granular test we could. We had a hypothesis that when we looked at what is the business question we’re trying to answer with this test suite? That’s part of a hypothesis in your testing worlds.

What do we think we’re going to see from that? Is it okay, “Do we think we’re going to merge code if the test fails? Or are we going to prevent code from going further down the pipeline? And how fast do we want this to happen? We obviously don’t want to wait four hours for results, is 10 minutes fast enough? Is one minute realistic?” And playing with our timings there.

And so we started to design these small experiments, and maybe, “Okay, let’s build a test, let’s add a few more tests. Let’s evaluate that risk that we’re going through.” And all the time we’re hypothesizing. Even when you’re doing a risk-based testing approach, you’re still creating the hypothesis that this is a risk that we need to address. And in what layer of testing do we need it?

So you might be wrong. That’s okay. The important thing is to reevaluate and say, “Oh, no, this could have gone at the API layer, or “Oh, no, I think we really need this and a UI test.” The important thing is that you’re trying, you’re doing this in a way that gets you fast feedback, that lets you see the results of what you’re looking for and then revisiting it. “Okay, did we see what we wanted? No. Okay, is this really a risk? Or is it a bigger risk than we thought.” And re-evaluating where you want that test introduced, or maybe multiple layers throughout your stack.

So that’s kind of how I approached it. Otherwise, it was too easy to get overwhelmed thinking I have to fix testing in one shot. And otherwise, it will take me a year to get something out the door. But until this, let me show you what we achieved this spring. Maybe we didn’t get it as fast as we wanted, is it because of the test? Or is it because of the pipeline? Where do we need to make a fix or adjust and do another experiment and keep trying until we see those improvements or don’t see improvement and then say, “Nope, that plan was trash, let’s try something else.”

Federico:

And I feel okay about saying that. Right?

Ashley:

Yeah. You have to be okay.

Federico:

Yeah. Now, because I think that there is another waterfall approach to innovation, I could say, which is imagine, I am planning to migrate from Selenium to Cypress to just think of something, right? And someone does a proof of concept and says, “Okay, let’s do this.” And once you are doing the migration, you don’t want to be wrong, and you want to continue and maybe if you have the mindset of finding out if I’m wrong and saying it at the proper time it’s a completely different approach. Right?

Ashley:

Yeah. And I think you can do that at the appropriate time. If you make your experiments small enough. You might say, “Okay, the prototype that we had, or the trial we did, it addressed these types of things, we’re about to now explore a different level of complexity. Let’s see if we think we’re gonna see the same gains there.” So maybe it worked to migrate, in these more generic examples, but now we’re about to introduce a lot more complexity. So what does that experiment look like? What denotes success? What marks, maybe we need a different approach in being able to look out for those and maybe you can instrument it so that you’re automatically told that it’s working or not, preferably.

We took a similar approach when we were looking at… We have a product called Collaborate, which is very similar to Zoom, it’s for classrooms, and we started to look at what happens if there’s 40,000 people online at the same time on a call, not even on the call, but just on the same server. 

We had not done testing like that before and trying to convince an executive, “I think we need to test this in production. We need to inject a lot of load. We think this is what’s going to happen. Here’s where we can hit the stop, everything’s fine. We’ll go back to the way things were buttoned.” Or, “It’s fine.” And people don’t even notice, they don’t notice any latency or the system doesn’t shut down, that would show success. But as soon as we started to see, we had to really design out. Okay, we’re going to hit pause if we see this one little thing start to blip as we start injecting more and more.

So being able to craft your experiments in a way that’s also safe, and in a way that gets you back to your original state, super critical, right? And with that work, we started to see what happens, maybe you start going more into chaos engineering, what if we take down this availability zone? What happens? Those are very carefully planned experiments. It’s not just, “Let’s go blow it up and see what happens,” kind of thing.

Yeah, I think I was just saying we are risk mitigators and how do we do that best, whatever that experiment looks like. And it was a different mindset for me to start thinking of things in terms of experiments. But when we first started doing that, before I really learned about the State of DevOps Report, when we started looking at, what would an experiment in production look like? That’s when almost everything I started doing kind of clicked. And I was like, “This makes sense in almost everything that we do.” And thinking through it that way.

So really learn that craft of the hypothesis statement, the measurements, the time that you think you’ll see success by, because you don’t want it to go on forever. All super critical components to think through.

Federico:

Yeah. So talking about learning. And moving on to a last couple of questions… I would like to ask you for a book recommendation.

Ashley:

Okay. So I have talked a lot about psychological safety. So I would be remiss if I did not recommend the book, The Fearless Organization, by Dr. Amy Edmondson. And in this book, she focuses on the importance of safety in multiple dimensions and how it’s really the underlying factor in effective teams. The impact it has on innovation, without safety, you kind of quash innovation. You have to be able to fail and make mistakes and raise issues to be able to innovate.

But what I really like about it, she tells a lot of stories from other industries. It’s not just focused on tech, even though she did do a really interesting project with Google called Project Aristotle, where they wanted to dive into what is the underlying factor, what makes an effective team.

But she also talks about Volkswagen. And what was the underlying cause of their whole kerfuffle, when they had the scandal of low emission vehicles not really being quite so low, but it was a result of psychological safety and a lack of it, they were afraid to raise those issues as engineers.

It’s fascinating case studies that she puts in that book. And I always like to read about other industries, because so much of it, we think things are unique to tech, but they’re not. I mean, she also talks about the medical fields, and the ability to raise issues, whether you’re a nurse that’s trying to say, “Oh, I think you made the wrong dosage to a doctor,” do they feel safe to do that? Or are they shut down and told, “No, you’re not a doctor, I have this. It’s fine.”

But there are real life altering implications if you don’t have the safety to raise those issues. I feel very fortunate that ultimately at the end of the day, I’m not doing medical software, I’m not doing life saving software, I’m not sending somebody into space. So my mistakes, maybe a little less weight or less consequences, but we all strive, we don’t go in thinking how can I destroy somebody’s life today. We all hopefully are on the same team in building something of value together.

Federico:

Yeah, totally. And maybe if there is something going wrong, the best thing to do is to raise your hand, ask for help. And try to be part of the solution, as well.

Ashley:

Absolutely. Yeah.

Federico:

Yeah, totally. Okay, and what about habits? Do you have any habits to recommend forming?

Ashley:

Yes, the one I’ve been really working on this last year, it’s still, I have it in progress. But I’ve really been focusing on a reflective practice. And what I’ve found, especially during the pandemic is, it’s helped me cope with a lot of change, whether it’s all of our lives got upended last year and throughout this year, and sometimes other people are finding themselves in lock down again, it’s a lot.

So being able to reflect on what changed, how am I reacting? Why am I reacting this way? How have I reacted in the past to this? What helped me get through it? Other things that you can reflect on are, am I working on the right things? 

Every morning, I spend 15 minutes looking at my calendar and okay, is this actually helping me achieve the goals that I set out for, for this quarter? Or is it distracting me from that? Is it worth my time? And being really ruthless with my calendar. 

It’s very easy, especially in a shared services organization to be asked for a lot of your time in many directions. And it’s super important to take that lens of how am I providing value? Is this helping me achieve my goals? And it’s okay to say no, build that practice. As a person that naturally wants to please others, it is very hard for me to say no, but I have to work on that a lot because I cannot be in five places at the same time.

Federico:

No, it’s part of recognizing our own limitations.

Ashley:

Yes.

Federico:

And focus. Yeah, totally. What you were describing was the personal retrospective that you mentioned before.

Ashley:

Yeah. Right? It’s super critical, but it’s something that I haven’t done enough of early in my career, but what it’s helped me do is craft the role. I didn’t just say, “Oh, I see this business gap, we need this.” I also reflected on what are my own personal values? What do I value in a team? What are my principles? And then how does that align to what the business needs? Because if I don’t have that reflective practice, I could still be doing a lot of work, the business needs, but I might not enjoy it so much because it maybe doesn’t align with my internal value system.

Federico:

Yeah. It’s really important to connect with your own body.

Ashley:

Exactly. Yeah. Your interests, what the company needs.

“I think there’s this lovely little circular chart of your interest level, your values, what the business needs, and where you start to see the magic. That’s kind of what I’ve been experiencing in the last year.”

ASHLEY HuNSBERGER

Federico:

So, Ashley, last one. Is there any way to connect with you?

Ashley:

Yeah. Find me on Twitter. I haven’t been as involved in the industry as I like to be this past year. I just got a little bit of Zoom fatigue, admittedly. So I kind of withdrew from conferences, but I always love to learn from people on Twitter. We love to kind of crowdsource problems and I love the testing Twitter sphere. To find me there, @AAHunsberger or just reach out. I mean, I’m on LinkedIn, not so much, but people DM me there too, if you don’t DM me on Twitter, that’s fine.

But otherwise I think I’ll be at SauceCon, I think in April. So just waiting to hear more from the organizers and I’ll be on a panel for testing. So I’m pretty excited about that. I totally forgot that was coming up too.

Federico:

Amazing.

Ashley:

And I’ll be on a webinar as well for STP where I’ll be talking about self-care with Elena Wiberg and Angela Riggs. So I’m really excited about that conversation coming up.

Federico:

Okay, amazing.

Ashley:

Totally forgot about those things. I said I had nothing to promote, but I do.

Federico:

You’re giving a lot of yeses!

Ashley:

I know, I was not very good at saying no this year, but I think I’ve said no for an entire year. I was like, “Okay. I can say yes to a few friends.”

Federico:

That’s amazing. Ashley, it was a pleasure, really. Thank you so much for all your knowledge and experiences, everything you shared. Thank you.

Ashley:

Thank you. Have a good one.

Federico:

You too Bye-bye.

Ashley:

Bye.

Did you enjoy this episode of Quality Sense? Explore similar episodes here!

Recommended for You

Tags In
DevOps
225 / 437

Related Posts