S3E5 Delighting Your Customers - How to Craft Meaningful UX as a Content Developer with Ellyn Hassell

Zohra Mubeena-Mutabanna: 0:04

Hello, listeners. Welcome to Inside Tech Comm with your host Zohra Mutabanna. In season three, we shift our focus to shed light on why Technical Communication is a core business asset. In this regard, we will speak with guests who are our stakeholders, such as product managers, marketing professionals, UX designers, QA and customer support, who engage with writers to create a seamless experience for the customer, and meet business goals together. Let's get started. In our previous episodes of season three, we have had conversations with stakeholders that we have worked with. In today's episode, we will speak with a writer who has worn several hats and earned writers a seat at the table with her efforts. Without further ado, I bring to you our guest for today, Ellen Hassel. Ellen is a Senior Principal Technical Writer at Blackbaud. She leads multiple efforts around UX writing and User Assistance patterns that promote innovation and consistency. She supports several development teams and collaborates across disciplines to create meaningful impact throughout the company. Hey, Ellen, how are you?

Ellyn Hassell: 1:20

Hey, zohra. I'm, well, thank you so much for inviting me on your podcast. I'm very excited to talk with you today.

Zohra Mubeena-Mutabanna: 1:26

I am equally excited to be talking to you today. We work together, but this is my time to pick your brains. Yes, really get to know you.

Ellyn Hassell: 1:35

Yes, yes, I'm excited. You've been such a delightful addition to our team. And we don't work directly on many projects. But we do we do a few. And I love that. But this is a really wonderful time, a full hour with you just one on one. So I'm gonna pick your brain a little bit too, if I may.

Zohra Mubeena-Mutabanna: 1:51

Let's go for it. Let's let's pick each other's brains. Okay, I get the first shot at it. Okay.

Ellyn Hassell: 1:56

You got it. And tell us a little about yourself. Well, you said a mouthful for me. Wow, that was a wonderful introduction. Thank you so much. I've been in the business for, I guess the business of technical writing for including my education, I guess, 25 years now, maybe 27 years. So I've been at Blackbaud for 20 years. I just celebrated my 20th anniversary in March. So I'm very excited about that. I came from an actual technical writer background, I went to school at East Carolina University for that. And it was kind of a newer program at the University at the time. And I knew that I loved languages. I knew I loved Spanish, I ended up minoring in Spanish. And but we had this interesting technical writer track that was part of the English umbrella. So I latched on to that, because I didn't think that I was interested in teaching. I was not interested in teaching at the time. So I was really, you know, I'm a very organized kind of list driven person. I'm, I like the technical side of many, many things. So writing and technical things. Well, let's put those together. That's kind of like a match made in heaven. So I went with that track. And I've not regretted it ever since basically, my first job out of college was Blackbaud. I was actually still in graduate school when I began at Blackbaud. So yeah, here I am, 20 years later. And I've done a lot of different things. I've worked on many products at Blackbaud. From fundraising to the financial side, and also leading lots of other side projects that we'll get into in a little while, I'm sure.

Zohra Mubeena-Mutabanna: 3:24

Okay, so as I'm listening to you, Ellen, I was like, so straight out of school, into technical writing, and what a treasure you have been to the field. And as you were saying, organized list-driven on whatever project we work together to the small ones, it comes through.

Ellyn Hassell: 3:44

I's too much sometimes.

Zohra Mubeena-Mutabanna: 3:48

Perfectionist. So I think that perfectly describes you.

Ellyn Hassell: 3:53

Well, thank you. Yeah, I think it translates into my personal life as well. But I say I'm I'm a list-driven, but I'm flexible. I can be flexible.

Zohra Mubeena-Mutabanna: 4:01

And I say it as a compliment. Because when we are doing UX writing, you want, brevity is important. And I think when you said list-driven, I wasn't thinking as a 123. But more as how can you be concise? How can you be specific? And from that, you know, you really helped me focus when we are discussing about our UX, but we'll get into it.

Ellyn Hassell: 4:19

Yes, we will.

Zohra Mubeena-Mutabanna: 4:20

But it was just an image that I'm like, yeah, that is Ellyn. Oh, gosh, yes.

Ellyn Hassell: 4:25

My husband would say the same. He might not have I don't know, he might have a different angle, but I get things done.

Zohra Mubeena-Mutabanna: 4:30

You've been at Blackbaud for a long time, as you said 20 years. So first of all, congratulations. I think that's an achievement in itself. You've done many things at Blackbaud. Can you share with us what that journey has been like?

Ellyn Hassell: 4:44

Yes, yes. So I started out as a documentation specialist. I know this, I guess you could have a podcast just on names for the industry like what do we call ourselves?

Zohra Mubeena-Mutabanna: 4:53

Great idea. That's a fantastic idea.

Ellyn Hassell: 4:56

Well, seriously, because as if your listeners are looking if you've got a subset of people looking for ways into the industry, you know, being well versed on what types of jobs to look for, they could really be under a variety of names. But anyway, that could be a whole other topic. Thank you. Yes, sure. So documentation specialist I, and I, you know, I knew that this job was exactly I'd be doing exactly what I learned in school or what I was still learning in school because I like I said before, I was still in my master's program was finishing up, but I came in, and our team so so for your listeners, Zohra and I worked together on the strategic content development team. So SCD I might refer to that acronym throughout this time together. But the SCD team wasn't an SCD team. At the time, we were split up and we were split up in multiple teams, we were just called documentation. And we supported specific products. So I came in supporting the fundraising side. And basically, that's all I did, I worked, the development cycle was waterfall for your listeners, that's a long development cycle, as opposed to something like agile, the agile framework, which is what we use today. And now I support multiple teams, and we're in an agile framework. So Zohra I support fouir teams. And that is not unlike, I mean, that's very common. Across the team, writers are going to support two, three or four teams development teams at a time. So it's not, we're not siloed, supporting just one product the way we were 20 years ago. And so through that journey I've had, I've been able to touch multiple products, I've been able to become kind of a SME on many different things along the way. Right now I'm in the financial side of the house, that's where I work primarily as a writer. But the projects along the way have grown. I mean, I've been exposed to so many wonderful projects just within our team, across RDO, and even across the company. So I think as I've grown in my career, my job title has changed multiple times. I've grown in my career. But I've also grown in my just my expertise in the field, basically, not as a writer, almost doing many, many things, project management in a way, I'm not a project manager. That's not my title. But I've been leading a lot of projects over the years that helped me exercise those skills. I think as you grow in your career, specifically, at Blackbaud, as you grow, you're going to inherently just take on those extra projects that are going to stretch you in multiple ways, not just as a writer. And so that's the wonderful thing about sticking. But for me anyway about sticking with Blackbaud for so long is I feel like I've done so many different wonderful things. And I've met a lot of great people,

Zohra Mubeena-Mutabanna: 7:37

Uou must have really stretched yourself to support not just these multiple product teams/ scrum teams, but also kind of be hands-on with the new tools, skill sets that you picked up. Did that feel like something that came naturally to you or was it challenging? What did you do to kind of, you know, grow those skills?

Ellyn Hassell: 7:59

I can answer that from two different angles? So first of all, how did those projects even come my way? I want to speak to that part. Because for your listeners, specifically, one thing I think that's really important is to try to identify gaps, as you're growing in your career. What are you seeing process wise, for example, in a project that you're doing, or maybe something that could be implemented, that isn't in place today, something that could benefit your team that could benefit across your discipline, or even across the company, you can stretch yourself by really thinking outside of the box that way, and really just trying to hone in on things or processes that could help projects, for example, anything that could help. And we can get into specifics if you'd like. But anything that could help make the communication better between team members or communication better across the company or reference material or, or meetings or anything that you can really jump on, that can improve a project, a process or some level of communication. And so you construct yourself that way by just not just writing all the time. Like we're not just writers, we do so many different things. But you can also kind of like think outside the box, how can I make things better? What are the gaps? Where can I fill in? And then once you figure that out, once you have an idea once you can get it can be small, you don't have to make this grand gesture. It doesn't have to be some huge project that you implement. It can be something very small, that can have very tangible impacts. And then once you do figure that out, or you do find an opportunity stretching yourself, like for me, I think project management, they I guess I let for lack of a better way to describe something like that a project management type of task is maybe something you're not as familiar with how to do; maybe you didn't go to school for that; maybe you've not even had any training on how to do something like that. And so you can stretch yourself by just diving in and just trying different things, especially if there's a gap and there's not a process in place where there isn't a project in place and you're kind of starting it from scratch, you have the ability to mess up or figure things out along the way. But I think stretching yourself really, you would need to be able to be flexible, be willing to fail, I mean, for lack of a better word, fail a little bit, figure out how you can do better, and bring people along with you as you go through the journey for a particular project. So a lot of stretching there.

Zohra Mubeena-Mutabanna: 10:25

Now, as you've gone through this journey, and you've you've stretched yourself, and you've, you're supporting multiple teams, you are also doing some things that are out of the box, for example, you're leading the whole, the whole UX effort. What prompted this need for more collaboration with UX on our team? Yes. SoI have to start when I started black when I have to start way back then because the way we interacted and collaborated with UX then 20 years ago, versus what we do today. I mean, it's changed so much. So let me just kind of go back in time there for a minute, when I joined the team UX was we were definitely two different tracks, two different disciplines. But our paths would cross like I mentioned, waterfall I mentioned, you know, we would have to collaborate on the design specs, usually they were could be 100 pages of a design specification for something. So we would have to collaborate with UX trying to understand or ask questions about prototypes, and things like that. But our team has always been very, very good at not just okay, that's like the lowest common denominator, you have to work with your UX in that way. But our team has always had this extra drive or extra desire to work with UX, we used to do a lot of usability back in the day, where we really didn't have a lot of formal patterns that we were following, even across the company. And UX definitely did their research. And there was user research going on and all of that for sure. But SCD or I guess you documentation at the time, which is what we were called, you know, we were super interested in that we were very interested and we wanted to learn more about how to implement that. What could we do to help fill those gaps? Can we help you out and so early on, we definitely established a partnership with UX on some of those early initiatives on implementing usability in your company. In fact, that was one of I presented, I think I've presented multiple conferences, but that was one or two of my specific presentations was about building usability and your company, either on a budget or for free. And UX was a big part of that back then. And so that was something that was you talk about something outside of the box outside of like your daily, I guess, job description, that was something that we really worked very hard to implement with UX, and they were wonderful. So even back then, while we were looking at different things, and we were working with UX kind of on different things, we've always had a wonderful relationship with them, a wonderful partnership. So fast forward 20 years. And it's just, it's just building and building through the years, you know, and it really has a lot to do with the technology to the things that we're able to do reaching out to customers, getting user feedback, discovery, all of these things you've seen evolve over time, which allows us to do our job much better, much more efficiently. And we've had wonderful collaboration that way with UX over the years. But fast forward to today with with the actual patterns, the more relevant things that we're doing right now, from discovery from sitting in on Discovery calls to the patterns work that we're doing the user assistance patterns work. That's really the meat of what we're, we're working with UX on today, in addition to of course, the UX writing, I mean, that's a huge part of what we do as well, UX writing. But yeah, the there are a lot of initiatives when I mentioned User Assistance patterns, and just trying to figure out what it is. We're trying to figure out what patterns exist today, what patterns could we create in the future that could be innovative and help delight our customers. And we work closely with UX on that, as we're working on UX writing, and we're going back and forth about label changes and better error messages and all the things that go along with UX writing. We're also looking at the patterns to and collaborating in that way. There's so much to unpack there. There's just so much that we do with them on a daily basis. Any given day, we're working with UX. I mean, there isn't a day that goes by that we're not working with them. And it's wonderful because they lean on us and we lean on them. And we have just such a terrific relationship with UX. Our UX engineers, just they are fantastic. Coming out of a pandemic. I will say most companies are facing like high turnover or you know, there's just everyone's hiring. So we have had some newer junior designers come on board and I have to say it's been wonderful to watch our team, the SCD team members be able to mentor and help the newer kind of junior UX engineers along the way to kind of onboard and understand what it is we're trying to accomplish? And how we can, you know, partner on a daily basis? Wow, I am so impressed. First of all the word that you used "lean on" each other. Yes, right? That is so critical. Because when you're in a business environment, if we as writers are siloed, nobody's going to succeed.

Ellyn Hassell: 15:22

Exactly!

Zohra Mubeena-Mutabanna: 15:23

Right! So you have to, it's not just partnering for success, but it's also leaning in on each other because we bring different skill sets. And, and we can be there for each other. And those discussions will only build bridges. I love that word leaning on each other. So that and then the second thing that you said was helping Junior UX engineers on board. That's I never thought of it that way that we as writers can sort of participate in that effort. I think, as a writer, we also have I have, maybe I have an imposter syndrome. I'm always questioned what value am I bringing? And you give me this interesting insight that, hey, you know what, we also help with onboarding UX engineers, the junior the new ones that are joining the team, and the leaning on each other? Yes, that's just beautiful. I want to kind of step back a little bit and ask this question. You said way back, when you started, our team was called documentation.

Ellyn Hassell: 16:25

Yes.

Zohra Mubeena-Mutabanna: 16:25

And there's a very specific reason why I ask this. On LinkedIn, there are so many discussion groups. And on those groups, I've seen this question come up several times. What do you call your team? And I feel when I have been in places because I have, like you, I've been a technical writer for almost two decades, Ellyn, I've had the good fortune to be at many places. I've worked with small companies with large companies, but most places have called documentation as "documentation" or "technical publications". And I feel what Blackboard has done, has sort of stepped that out of the box branding of our team. SCD -Strategic Content Development, to me when I heard that when I was being interviewed, and when they said, you're going to be on the SCD team. I'm like, What is SCD? But I didn't figure that out until I had started. And I bring this up, because if anybody that is trying to elevate your profession, is to be thinking about how you brand your team as well. So my question to you is, was that intentional? What was that journey like?

Ellyn Hassell: 17:31

Oh, yes. So okay, so going back to documentation, we used to be I think user education. At one point, that was our more recent title for the team, I believe user education. And now strategic content development, I think, while our manager, you know, he was very, and I think he's been a guest on yours, David. David. Yes. I think maybe one of your seasons, your past season. My second, not this current season? Yeah. He's always kind of looking for cutting edge everything. So yes, we were called documentation. And then I think we shifted to user education. That was our more recent name, right before strategic content development. And I think it's just reflective of the industry and what we as writers do these days, we don't just write documentation. That's kind of a dated term. So pulling that out. The team name was very smart. I think our you know, David has done a great job of constantly assessing the team name, and also our job titles, too, and making sure that we that we match what is happening in the industry today. So definitely, strategic content development is accurate. And will we might change next year. Who knows? We'll certainly evolving,

Zohra Mubeena-Mutabanna: 18:44

But has that positioned us in a different way?

Ellyn Hassell: 18:47

I think we're just I think when folks are looking for jobs at Blackbaud. Certainly I think they probably it may be twofold, I would imagine. They probably think well, this is very interesting. This encompasses a lot of different things. What exactly am I going to be doing here? What does this team do kind of like what you were commenting on Zohra? Like what is SCD? But also I think it also lends itself during the search process when we're, when we're looking for people. And when people are finding us. It's not just such a very, it's not a small tunnel of job opportunity or job. Money to rephrase that. Sorry.

Zohra Mubeena-Mutabanna: 19:22

I think you're right. It is pretty broad. It is quite broadly encompassing. So it actually allows us to onboard varied talent.

Ellyn Hassell: 19:31

Yes, definitely. It allows us to have access to more people, but and then more people are interested in us for sure. Because the it's a broader, a broader topic, or it's a broader role that we're advertising, I guess. Yeah, our job description. The job description is definitely it's intriguing when you have something like that as opposed to you know, just documentation. Documentation in itself carries such a, I just think it's so dated, you know, you think of PDFs and which there is still a value for PDF documentation that hardcopy but wait for sure. But I think it's just reflective of how the industry has changed. And also, it's more encompassing of what we do.

Zohra Mubeena-Mutabanna: 20:10

And I think you said, trying to be cutting edge and trying to be reflective of what's happening in the outside world, trying to keep up with that is very important. And you articulated that really well, we don't want to date ourselves, we want to be you also, I think, said that this might be a little too futuristic, which is awesome, because it's a direction that we want to move towards, rather than be stuck in something that is not where content is anymore.

Ellyn Hassell: 20:37

Yeah, yeah. And yeah, it could change again, especially as we take on more, me, gosh, just the UX writing piece is so relevant right now to what we're doing. And, you know, who knows what our job titles might morph into, or even the team name might be a little bit more reflective of that as well, in the future? Who knows. But I commend David for yeah, and the team managers too, they really do a good job of assessing and trying to make sure we're up to par.

Zohra Mubeena-Mutabanna: 21:04

That's true. When I came on the team, I felt empowered, because I thought of myself as a content creator. I wasn't being siloed in. So for me, as an employee who didn't understand what that was, it was still intriguing. And I'm like, this offers me something more than just typical, traditional documentation. And that's been my experience. So you're definitely right about that. It allows for a lot of room for you to experiment, to grow, even within the team.

Ellyn Hassell: 21:32

Yeah. And you talk about empowering, I will say I remember numerous occasions where David and the team managers would actually ask for our opinion, that's pretty cool. What do you want to be called? What do you think that you do? You know, on a daily basis, and how does that reflect in your title, and so we've been able to chime in now and then, which I think is empowering.

Zohra Mubeena-Mutabanna: 21:51

I'm doing my happy dance here. Which is, again, pretty rare. Given that I've been in several companies where we've not had that opportunity. We've been siloed, that this is what you're going to be, you don't have an opportunity to contribute to that discussion. So that also is having a seat at the table. In my opinion,

Ellyn Hassell: 22:07

I think so for sure. Being an advocate for yourself and what you represent in your day to day activities, your role, your title, all of that. Yes.

Zohra Mubeena-Mutabanna: 22:15

You mentioned that usability was always there from the time you started. And you had that partnership. Most companies that I've worked at, maybe like the non tech companies, well, even the tech companies actually did not have a UX team. I'm talking about maybe even 15 years ago, some of the companies that I worked at, and then the companies that I did work at did have UX teams, but there was no collaboration. But it appears that at Blackbaud, the writers always had access, and the engineers always had access to writers. Is that right?

Ellyn Hassell: 22:46

Sure. Yes, even back? Yeah. 20 years ago? Yes, definitely. We had teams, it wasn't agile, but you know, it was the waterfall. But we still have teams of different stakeholders that that worked on a feature set that tell you what it's so to even say this out loud makes me chuckle because I just I'm like, how did we have so much time? I feel like we must have had so much time on our hands back then because we supported one feature. I've supported maybe one or two features for a particular product. Nowadays. I'm like supporting all of these things. It's it's amazing how we filled our day, all those years ago, but yeah, we did. We had access to developers. That partnership was great than two, we've been focusing on UX, and that partnership, but I have to throw in that developers also were very instrumental in our working groups as well, for particular feature because we were able to ask them questions. As we were testing, as the writers were testing and trying to figure out like, what am I going to say about this? How am I going to write documentation to support this feature? We had technical questions. How does this work developer? How do I do XY and Z? And what if I did something different, and I need access to this environment to be able to understand and play around here and mess up and create things and figure out what I want to communicate to the user to help them get through a task. So UX and Dev, I feel like we were on board with them from the beginning. And then it's just grown. It's grown tremendously. I can't imagine any day that I work, or not being you know, having a dev or UX involved or even a product manager. It's just such a tight collaboration. Rarely are there days where I'm just working by myself or with just a writer, or a couple of writers. I mean, we're just so intertwined these days.

Zohra Mubeena-Mutabanna: 24:31

Yeah, I think that's my journey, too. It's all so intertwined. But you do something cool. That's where I'm going to sort of steer towards. You talked about the UX patterns, and I see how mature our UX patterns are at our company. We have office hours around UX writing. These are these are best practices, in my opinion. But coming back to the UX patterns that you talked about, how did those come to be? Because I benefit so much from them. And how has that partnership been? For us? I mean, first of all, how did that happen? And then we can talk about how this has benefited both teams.

Ellyn Hassell: 25:10

The patterns work came about because and this was years ago, I don't know, I want to say maybe even six or seven years ago, six or seven years ago, maybe six, five or six, we were moving from this kind of database, the products that we have supported for all these years, since we've even been a company have been tied to a database. And so I would say, six or seven years ago, you know, we're starting to shift over to a different architecture. And with that, we were seeing some we were seeing very, so let me back up. And I have to mention SKY UX, that's a framework that we were using to shift, you know, a lot of our what you were seeing kind of in this web view, this modern view, US are leveraging components that are built from the SKY UX framework. And so as we're shifting architecture, they were shifting, we were forced to look at how the different patterns, how those different components, the SKY UX components were being implemented across the solutions that we're switching, not all use solutions and products interchangeably. I apologize to your listeners. But they mean the same thing. I mean, the same thing, when I say that, we'll stick with products. As the products were moving over, we're starting to see the same components being used across the board. And they were being used, sometimes they were being used inconsistently. So a small group of us, we were tasked with starting to look at these different patterns, the user assistance patterns, the way we were triggering help, the different the different help elements that were inside of the UI. But we are that also extended, that effort quickly extended to just patterns in general. So we were seeing starting to see different inconsistencies across the board. And so we were tasked with trying to form a group and UX was involved in that group. And I think it started out with, it's pretty much just UX and SCD at this point, I think a few other disciplines have kind of come in and out to offer some expertise on something here and there. But for the most part, it's just been the two disciplines that we meet monthly, sometimes more, we were tasked with just looking to see how we could improve. Number one, are there different patterns we can implement? Are there ways we can do this better differently. And also, let's correct some of the inconsistency that we're seeing. And so that went on for years. And now it's morphed into. I mean, these days, we are looking at the guidelines, we're helping create and update the actual guidelines that our entire company uses mostly audio, but like it, the guidelines that we create are open to everybody internally, we're hoping to update and craft those. So we've kind of elevated the I guess the scope of the project from what it was initially to what it is now, that's a very timely questions or because even today, like as, as recent as Friday, today's Sunday, we're recording on a Sunday, we're trying to actively recruit SCD team members to get on board and help actively go in and update these guidelines and work with us. There's a working subgroup that is being formed, as we speak, to help get in earlier and take some of the pressure off of us actually getting the code update. It also benefits the SCD team, because any technical skills, the more technical we can make ourselves, the better. So we're kind of bettering ourselves in that way. We're picking up extra skills. So that's really how it came about. And it's just taken off. And now we have a patterns council. So there's like a whole other layer of process around it, where you can submit a pattern proposal. And that proposal goes through an audit process and people kind of weigh in and figure out is this the best, the best type of pattern that we want to implement? And if so let's go ahead and add it and or let's test it, let's figure it out. Let's get everybody to weigh in on it. And then we'll create guidelines. And so there's a little bit more of a process around that than ever. I mean, now more than ever, but it's a very timely question. I say that just because we are literally trying to do much more of that and have it be much more of a closer collaboration with SCD getting in there as early as possible and helping out. So yeah, that's about pattern. The patterns work is just an anybody can help anybody from SCD can help. You have many choices, you don't have to be the one going in and adding the guidelines. You don't have to be the one that's trying to come up with innovative patterns. I mean, you can help in so many different ways, even just testing a new pattern or looking for inconsistencies across different products. So there's a lot of things you can do there to plug in

Zohra Mubeena-Mutabanna: 29:46

That's a lot of information in there. So I'm going to try and sort of, I guess, tear it apart a little bit so that I can process it. A lot of information that I don't want the details to get kind of lost. Did I say that right? I don't want to good to go had lost in the details. I suppose that's what I meant.

Ellyn Hassell: 30:02

Sure.

Zohra Mubeena-Mutabanna: 30:03

So one of the things that you said was getting in earlier, which is I think super important for all parties concerned. Now who comprises the committee or you said the council?

Ellyn Hassell: 30:14

Yes, Patterns Council. I don't think that's their official name. That's what I call them. But it's like a gatekeepers. Yeah. So it's our SKY UX engineers. And then David represents SCD; it's a small number of people. And then there's actual SKY UX, or sorry, its designers like UX engineers. So there's basically three sets of disciplines represented.

Zohra Mubeena-Mutabanna: 30:38

I see. And I think you sort of explained to our audience, what patterns are, do you have anything else to add? I understand what it means from my point of view. But do you want to elaborate on that?

Ellyn Hassell: 30:50

There's two different things that we look at. And it's really the framework that components I guess, the puzzle pieces that make up what you see in the UI? Are those being implemented consistently. And then we've got the user assistance part of it, like, how are we triggering help? What is our naming convention for these types of labels, or these types of headers. So there's kind of two facets that we look at when we're looking at patterns, and how they are implemented. On a page, for example, or on a screen, there's a lot of those different elements make up, they help to make, it's kind of like putting a puzzle together, honestly, you've got lots of different parts, lots of different pieces. And then you put them together to make this one nice, cohesive workflow. And sometimes those pieces aren't implemented the right way. Or you might be missing something. So that's where the pattern? Well, actually, I would add, let me take that let me backtrack on that just a little, because I think this is really important for users to understand your users or sorry, your audience to understand. You know, there's one thing the quality part, right, there's, that's one part that you have to make sure is there. And so as writers individually, it's important that each writer on their own teams is looking at these patterns outside of any kind of patterns meeting, and outside of this council that has formed, it's our job to raise those concerns and questions whenever we on our own individual development teams see something that is questionable, or we're not sure how to implement. And that's, I think, where the meat of the collaboration can come from between SCD and UX is that daily feature development, where you're right in the thick of it, and you guys are we're having to implement quickly, we're iterating, quickly, we're writing quickly. And that's where you have to do your due diligence as a writer, aside from any of those larger kind of collaboration efforts. And I think that's really important for your listeners to think about, as their, you know, their writing, you might have many listeners that aren't even in software, they may be in whatever, genre, or vertical. So it's important that they kind of take into consideration I think, what it is they do on a daily basis, in addition to all the other things that they could do as a group, across disciplines, and even across their organization.

Zohra Mubeena-Mutabanna: 33:07

Yeah, because I think consistency, your branding, the voice all that has to come through. Yes, this is the groundwork to present that.

Ellyn Hassell: 33:16

Yes, yes, I do. I think that sure they all play together. Sure. But when you start out with good consistent design, that makes sense, then you can branch off and and you can do, you can take care of all the other things that go along with it, like your marketing and how we're going to promote this and that,

Zohra Mubeena-Mutabanna: 33:33

In my day to day currently at Blackbaud when I, we have the opportunity, like you said, you're in the thick of it, and you see something that is not working, or you have a challenge or somebody else on the team may have done it. So you kind of can bring that opportunity. And I talk about this because, of course at Blackbaud we are fortunate to be on a large team where we have access to these resources. But even if you were to scale that down, being an advocate for yourself, and to question and to challenge, something that doesn't seem right, is a good thing that hopefully allows you to establish some best practices on your team. So far, everything that we've talked about sounds like it has been a pretty smooth journey. But like everything that happens has challenges. And I want to ask you- have there been any challenges along the way as we were trying to partner and collaborate or differences of opinion on how things are going to be done, how those were resolved? And I specifically asked this, Ellyn, because there are many, many writers out there who are lone writers on a team. And if they are trying to advocate for some changes, how can they go about it? So I just want to sort of hopefully I suggest that you keep that in the back of your mind as you talk about the challenges.

Ellyn Hassell: 34:47

Sure. There have been a few and so I'll start out with just time. Okay, so we like I said multiple times. You know, our writers support many different teams UX is in the same boat. Right now. They are attached to a specific dev team. but they don't always go to like, we don't always go to all the ceremonies, all the different meetings, because we just don't have time, I can't even tell you the amount of teams recordings that I listened to, while I'm driving, of meetings that was triple booked, for example, and I couldn't go. So anywhere between one and four meetings, I might listen to a recording every day or every other day, so that the time constraints are difficult. So we're all strapped for time that UX is in the same boat as us, we definitely support multiple teams. So even though you have a UX engineer assigned to your team, that doesn't always mean that they're going to be at all the meetings that you are in. So find some time carve out some time one on one, or a try to insert yourself into a triad or somewhere that you know, some platform meeting, whatever, where you know, UX will be there. And you can ask questions you can plug in. But a lot of times our collaboration comes through messaging one another, we do a lot with Slack and teams messaging. Sometimes that is just enough, because we're also busy. And we're doing a lot of that while we're in meetings. That is a challenge. But it's one that you can navigate, if you just are willing to kind of be on the same page, like, hey, I know you're really busy, for example, if you're messaging your UX engineer, but I really need an answer to this, or can we meet tomorrow, you know, give him some options. And hopefully they'll reciprocate that as well. But that that definitely is a challenge the time and the just the amount of projects. Another challenge, I think, especially if you don't already have a concrete relationship, or partnership that's well established, you can try. Well, what I always like, and this is just me speaking here, but listening. So you have to be really good listener, you have to be a great listener, you have to be willing to do your own research, if you want to bring a suggestion to your engineer to your UX engineer, then you should back it up. Whether it's something that needs to be backed up, because it's an accessibility concern, or an internationalization or localization concern, or even a usability concern, or even just simply, I'm a writer, but I'm also a human being. And I was going through this prototype, and I am so confused. And I'm just a normal person just trying to get through this feature. And I just can't, I think it's important to try to bring examples of why things might not work when you're talking about suggestions and bringing suggestions to UX, but also be willing to listen to maybe their point of view, like why did they design it that way? What are they getting from their end, like what that they've discovered in their user research or Discovery sessions that maybe you don't know about. And so maybe it has to be designed a certain way. And then you guys have to work together to make excellent labels, and excellent field names, maybe there's something that you just have to go above and beyond knowing that it could be potential pain point for the user, and you have to create really great help content for that, like a tutorial, maybe they need this broader overview picture. Because it is kind of a difficult area, or whatever it is that you can do to help, it might not be a redesign, it just might be better. Not redesign, but better elements, you know, make them stronger, make the word stronger on the screen, maybe add a little bit of persistent text, and maybe save, you know, this does need a little tutorial here, because users you're gonna have trouble with it. But I think just in general, honing those communication skills and having respect, just show respect. And be willing, willing to accept some pushback, there may be some pushback. But if you can just say, you know, for the greater good here, I want to delight the customer, I want to make sure that I'm doing everything that I can to make this a really amazing experience, help them get their job done, move through the task, let's partner together. And, you know, hopefully, that person will share those same sentiments and they'll be able to, you know, you can find a few minutes where you can go through and maybe brainstorm at least that's been my experience at Blackbaud. And implementing those that I guess that approach has worked really well. Because at the end of the day, you both want to delight the customer, and you both want the customer to finish their task and move on. And sometimes without even realizing they've consumed any type of help or anything, right, you want to make it so seamless for them. So it's just it's something that I think takes time. It might take time. So be patient, if you're listening to this, you know, and you're like, I don't know that I can ever do that. Or I don't know that I'm I'm shy or maybe I'm, I work with a really difficult engineer. Those are all real life, things that could happen. But if you're persistent, and you come with your research done and your reasonings and you simply show respect, I think you can go a long way.

Zohra Mubeena-Mutabanna: 39:50

I have nothing more to add to that. Ellen, you just covered the whole gamut of challenges that one can run into and I can like I said I've been in situations where I've been the the lone writer, and everything that you said, applies pretty well. And what we're doing at Blackbaud, it's sort of at a departmental level. But if you're if you are a loan writer, you may not have that opportunity. But everything that you can do to delight the customer is a step forward in the right direction. So that is my takeaway from everything that you just said.

Ellyn Hassell: 40:21

Yes, yes, I mean, and again, a little steps like I think with anything with everything that we've talked about today, so far, any incremental step that you can make, or you can take a bite out of this or that you know, is going to make such a difference. And you might not think that it will, but it most certainly will, because you can then establish a pattern for yourself, well, I was able to knock out, I was able to change these labels last week. And it's so much better. So this week, I'm going to move over to fields, or I'm going to move over to a different element in the UI. And I've and now my UX expects this for me. So now I feel good about it, he's expecting or she's expecting this for me. So now I'm going to move on to something a little bit more substantial in the UI, okay, a little bit of a bigger element, and then you just kind of like, keep going, and you just make strides and along the way you are, you're basically establishing trust with one another. And that goes a long way to if you can just think the work will naturally promote trust as you move along. And that's a big deal. That's a big deal with any colleague, not just UX,

Zohra Mubeena-Mutabanna: 41:29

right? I think that has to be the bridge with which you work, you know, establishing that trust, because without trust, you're never going to be able to move the needle forward. Something that I think from everything that you said, like, you know, you suggested, okay, you might want to look at fields today, tomorrow, you might want to look at error messages, or you know, as you start looking at it, we also have a style guide that we have access to, in your opinion, would it be a good idea as you and your UX engineer, especially in companies, where you are a small team, start putting that on paper, so that both have something to refer back to? And it's sort of like an understanding that this is what it's going to be like going forward?

Ellyn Hassell: 42:08

Oh, absolutely, yes, any kind of material like that, that you can put together. And you know, for sure, it will be used by other people outside of UX, and SCD or your your writing group. I mean, definitely anything that people can grab on to when they're trying to come up with terms or whatever I mean, marketing, even sales. I mean, if you have standards like that, and whether they're well established, or whether they're new, and you're trying to implement some type of standard terminology, for example, for the first time, then, yes, it can only make things better. We have so many guidelines, we have terminology guidelines, we have the component guidelines, the patterns guidelines, we have a corporate style guide at Blackbaud, we have a lot of different resources. But one key thing that I think I have tried, at least to bring together is is making sure we're all aware of what one another's doing. So we don't overstep, and then we don't have patterns that go against one another or terms that go against one another. So that's something that I actually worked on a project A while ago, it's still an active project, I just don't need it anymore. And that was a syntax project, where we're trying to come up with work with many different stakeholders to come up with a substandard terminology that mostly encompassed customer facing terminology. But that eventually would make itself obviously into the product, but also that sales could leverage and marketing when they needed it as well. And so yeah, I mean, I'm a big proponent of guidelines, they have to be kind of flexible, though, going back to the syntax project that just mentioned, when we worked on that we didn't want to be a bottleneck to anyone, but we had to make decisions at the time. Or else we would just be at a standstill. So we had to understand that like, hey, the things might change, the future might change, and we need to be able to pivot with it. But at this point, anything we can do to standardize will be beneficial.

Zohra Mubeena-Mutabanna: 44:04

You know, my follow up question to you is actually going to be in the book, the book club that we had. And the book that we read,"Don't make me think", one of the things that I was really intrigued by was design and UX can be subjective and preferential, it wasn't sort of I'm not reading it, quote, unquote, but something along those lines, and what you said, right, you don't want to be a bottleneck, you want to be flexible is the path forward. Is there anything you think you want to add further to that? Because I think you really articulated, you know, how do you get past that roadblock? Our goal is not to be a roadblock. But anything else you want to add?

Ellyn Hassell: 44:40

Oh, yeah, it just I just think that anything you can do to establish the standards, like I said before, but yeah, definitely being flexible. It's just so important that that you know, actually this goes back to being able to back up. Why am I making this word standard over this other word? Why are we going to choose this Well, because it has accessibility concerns. It has internationalization consequences. I mean, all of these things, you know, you can't just go into it, I guess, being like, well, I just like this word, because it sounds better. You know, there has to be a reason for all the things that you're doing. And I guess, yes, design can be subjective. Yes, it can be preferential, but it's always going to be. But I think having the guidelines in place, even though you're flexible with them, to an extent, can only help the process, it can only make, you know, maybe it takes away 60% of the ambiguity or 60% of the inconsistency, which is better than having it willy nilly all over the place. Right. So yeah, I mean, having those guidelines, and also it's a great place to start when you have to discuss something. So like going back, if I could just go back for a minute to the conversation about like, what if I need to talk to my UX engineer, but I don't know what if he's not, or she's not receiving the feedback, like, what do I do having a source of truth, even if it's the source of truth for the moment, even though it could change a little bit? Or it might, it might, depending on the development of that feature, for example, it's still great to be able to say, hey, here's a link to what was decided last year on this particular feature, or this component, or whatever it is a word even. So I thought we were going with this. And but I see it's different here in the prototype, let's talk about it. So it just really helps when you have something as a point of reference, that can help.

Zohra Mubeena-Mutabanna: 46:34

Yeah, yeah, I think that's a very good advice. That's very sound advice, that you want to back yourself up. And if you don't have something to backup, then that the source of truth that was established in at some point of time allows you to move the needle on that conversation. Yes. And and it takes away that subjectivity. And it allows you to sort of think outside the box.

Ellyn Hassell: 46:56

Yeah, and it's a great starting point for, you know, hey, this worked great last year. But you know, we've added these new elements, and we've sort of redesigned a little bit around this. So maybe we need to freshen this up. So it can be a great segue into potential redesign or potential different word choice, for example.

Zohra Mubeena-Mutabanna: 47:13

And you know, Ellyn, I've been in this exact situation, I mean, that's what prompted me to do this episode with you, because I've been in situations where I have either not backed myself up, or I did not have a source of truth to start with. Or I was told by somebody in Sales that this is the word I want because this is what I like. And I didn't know how to approach it. So everything that you said, makes so much sense to me personally, that I wish I had you there to sort of handhold me and guide me through those situations. And as writers, we are always, always put in that spot where we are challenged. And you have to prepare yourself. And if you if you put that source of truth in place, even if it is small, and get agreement on it, it makes your day to day easier when you are able to back yourself up. And that's something that I was missing in that role where I did not build that source of truth. And I could have thought about it and done it. And like you said, we are all constrained for time. Yes. And I was too. But I think we can start small. And I thought of these grandiose plans. I'm like, Oh, my god, how am I going to do this. But taking that incremental approach could have made my personal life so much easier, my professional life so much easier. And you know, I've made those mistakes. So this is a good learning for me to pursue? Yes.

Ellyn Hassell: 48:29

Well, it's a great reminder for me as well, I mean, because at the end of the day, I do lead some of these projects. But I'm also a writer, I am a writer, and I'm in the trenches with everybody else who's writing. And it's I come across the same challenges, I mean, literally on a daily basis, just because we are developing so quickly. And and we do rely on these guidelines, because of our development cycle is just so fast, and the guidelines, they can change. And as the components change, and as things are refreshed, you know, you have to constantly kind of update those guidelines, going back to the beginning of our conversation where we talked about good UX, and SCD partnering on the guideline updates, but but UX, excuse me, SCD getting in a little bit earlier, and getting in the code and helping when possible. That's where I spend sometimes the brunt of my week is around guidelines. Just because you know, you've got a large we have a large team that we have to empower to be able to do their jobs. And if you have out of date guidelines or guidelines that just don't make sense. You know, you've got to work. You've got to spend part of your day, making sure you do everything you can to update them and and get them the way they should be until something else changes. Right.

Zohra Mubeena-Mutabanna: 49:40

Right. Right. And you know, Ellyn, the part about getting in earlier in my episode with Matt rife. That's my second episode for season three. He is a UX designer and that's the exact thing that he's also asking for getting in the writers earlier. It's so critical. Yes, because you can usually move faster. Once you're past, you know, the later we come in the game, the harder it is because so many things are established by then. And coming in earlier allows you to pivot if need be. So I think it's so important for our listeners, especially our writers out there, or any other stakeholders listening to this, bringing in all stakeholders, writers, designers, researchers, if you have them on your team, even developers probably to have these discussions earlier is the name of the game. So thank you for emphasizing that.

Ellyn Hassell: 50:33

Yes, yes, it definitely is.

Zohra Mubeena-Mutabanna: 50:35

You also mentioned that you've presented at conferences now I'm super curious, because I have also done that. But we've not run into each other. So I want to know, what sort of conferences you've done, because that's again, earning your seat at the table. Please tell us about that journey.

Ellyn Hassell: 50:50

Yes, yes. Okay. So I have to start by saying that back at East Carolina, we were members of a local branch, a local STC branch, or I guess a call it a college chapter. Yeah, I couldn't find the word, college level college chapter. And we were actually given many opportunities to speak, based on what we were learning the classes that we were taking, and some of the side projects that we were working on in my master's program. So yeah, we were able to start right out of the gate, giving presentations at I think we even went to a district wide one, we traveled a little bit together as a group, I had a very small, there were probably maybe seven people, seven students in my, in my track. But yeah, I started out, then that's where I started giving presentations. And that was, of course, affiliated with STC, Society for Technical Communication for your listeners. And when I came to Blackbaud, I did not have children yet. So I was newly married, and I had all the kinds of time all the time on my hands. I feel like I don't have any time these days. But I was very interested in I felt very comfortable public speaking. So I definitely found ways to present different things. But one of the very first ones that I did present on was usability, when I was at Blackbaud, was about usability and building that usability in your company, I think it was even called"Building usability one step at a time". And it was pretty much geared to like on a budget or even if if your department doesn't have any money geared toward usability, how can you implement some things for free. And we talked about partnering with UX and all that good stuff. So to kind of come full circle with that. But I do think it's invaluable really to get in front of people and speak and it elevates you your status as a Career, Technical Writer, or whatever your title is, also, like researching tools, figuring out what you want to learn about that interests you and bring it maybe bringing that back to your team and you could you know, present to your team that way could end up being a multi discipline presentation. But yeah, I think that will be beneficial to you. If you can find ways to do that. Over time, as your career grows, and you and you grow in this industry, it's important to share and give back what you're learning. And not just to hold it all in yourself. But I do want to say for anybody that is about to present or can appreciate this as a past presenter, I have to tell you something funny that happened to me at STC is international conference, I was with a colleague of mine, and we were in Baltimore, Maryland, I think. Anyway, I was presenting on usability and I had I was so proud of myself, I had brought with me these cardboard personas, like part of usability and user research is about personas and understanding your audience. So I had literally developed these fake people with with pictures, and I had given them a whole title and a role at a particular organization. I had them, you know, these were my visuals for my presentation. And they actually were very effective because I had given this presentation locally. And I think I had given it to my team at Blackbaud. So like I had already run this presentation through and they were beneficial. And they helped because I did a lot of referencing of these personas. Anyway, I go and I set everything up. I had other visuals as well, I was so excited, so confident. And I thought, well, I've got just a few minutes before my room will start filling up with people. So I'm gonna go check on my colleagues. So I run down there, it was actually David. David used to not be our director or manager he used to just you know, he was we were all writers together back in the day, David has been at Blackbaud a really long time. So I'm like, I'm going to just go run and see if he's ready for his presentation. I had nervous energy to I was just like, I can't just stand here in this room and wait for people to filter in. So I run down there to where to his room and I'm like, Hey, you're good or good luck. You're gonna do great. And then I leisurely walk back to my room and I get into my room, Zohra, and my personas are gone. Um, my, all the different things that I can't remember all the different things that I had, but I had multiple other visuals and I had booklets and different things and they were all gone. And I couldn't I mean, I literally had maybe seven minutes before my presentation was supposed to begin. I cannot tell you the amount of fear. And just like, everything just shifted for me, I was like survival mode, like, what do I do? How do I, you know, all these people are going to come I know there's going to be many, many people, and I can't not have something for them. And I can't do this off memory. So I step out of the room, and I am looking around, the first thing I'm thinking is I need help, who can help me? Where could this stuff have possibly gone? What conference attendee would have ever thought about coming in here and taking this stuff? Like, what are you gonna even do with it. All these things are going through my mind. It was horrible. And I like my mouth is dry. I can't I can't even barely make sentences because I'm so distraught. But I found a staff member just kind of outside of my door, and I was like, I have no idea if you're gonna be able to help me. But all of my material is gone. I'm getting ready to present. And he's like, oh, oh, I took all of that out here. It's and he led me to this back closet area, I guess, like behind some partitions where they keep trash. And so he thought it was trash. So I was just cleaning up for I thought that all of this material was from the presentation before yours. And I was making sure this room was clear. I thought, you've got to be kidding me. So I got everything out. And I threw it back in the room. And people were starting to filter in and I'm like, Oh, welcome, welcome, just setting up. But I guess the bottom line for that story, the takeaway is, you can only be as prepared as you can be like, you would never have thought that would have happened, right? I never thought that would have happened to me. For anybody else who's who's has a similar kind of story, probably more or less in line of, Oh, we lost internet connection, or you probably have some kind of story where something went wrong. Or maybe your colleague got the flu that's supposed to present with you. And you had to do it all on your own. I mean, who knows. But that was definitely a learning experience. And I actually did have to think on my toes there a little bit because my, all of my material was disorganized. It wasn't where I wanted it to be. And so here's a tip, if that happens to you, or something happens to you, where you find yourself not in a predictable, like 100%, confident ready to go, I know where everything is type of setting, then just be transparent. I literally told my audience, I was like, this is a funny story, you're not going to believe what happened. So I have to apologize, because I don't have everything quite the way that I had it 15 minutes prior to this session, but here we are, they giggled a little bit. But I think it helped them feel, I guess, more comfortable with the information they were going to receive for me, they felt maybe more comfortable that they could ask me questions because I just let my guard down. I was like this is, you know, this is what it is. So we're going to kind of navigate through this together. And it really ended up being I think I had like 85 people in attendance. It was a great presentation. I had a lot of great questions. And people wanted my contact information afterward. And, you know, this was before social media. So I didn't have you know what, I had to actually give them a handout of my email and all that kind of stuff. But yeah, so that's a great takeaway is you can only be as prepared as possible. But the ultimate preparation is to be able to pivot when the unexpected happens, and to just be transparent. And know that you know, everybody's human.

Zohra Mubeena-Mutabanna: 58:25

Ellyn, as you were speaking, I was feeling the jitters. I'm like, what happened? How did you? How did you salvage the situation? And it's all about that, right? You have to pivot, you have to be transparent. And you have to let your guard down. Because, first of all, I'm so happy that everything worked out.

Ellyn Hassell: 58:45

Right, right.

Zohra Mubeena-Mutabanna: 58:46

I mean, I'm like what happened? But everything turned out well, eventually.

Ellyn Hassell: 58:51

Yeah.

Zohra Mubeena-Mutabanna: 58:51

And you were able to pull yourself up. Right, you're able to bootstrap and, and get the show on the road?

Ellyn Hassell: 58:59

Yes, yes.

Zohra Mubeena-Mutabanna: 58:59

Right. And I think that's important, because you're going to be in these situations. Oftentimes, you're ready to present and you you think you have everything under control. And something, there will be one variable that you did not consider. Right. Right, always. And trust me, a similar thing happened to me at the STC cap conference last year when I was presenting virtually, oh, and we had to pivot. And it was the virtual q&a session. We were done with the presentation. It was pre recorded. But then when it came to quick Q&A, myself and a colleague were presenting together, and we ran into a situation where the question was directed at me and I did not know the answer. And this was live Q&A that was going on. And we had to pivot, and it was okay for me to say, I will get back to you. You don't have to have the answers at that moment. Your situation was something scarier. No doubt. No

Ellyn Hassell: 59:55

Yes, it was. I know kind of I definitely value doubt. that what you just said about not knowing the answer, because

Zohra Mubeena-Mutabanna: 1:00:00

I realized that we've experience, especially with all the different things that we support these days and the different teams that we're on, inevitably, there's absolutely nothing wrong with admitting that you don't we're not going to know the answer. And I think people respect that, you know, I don't know the answer, I don't have it have the answer. But you'll at least try and get back to them. in front of me, but I will get back to you is, is a golden answer. And you'd rather give someone good information, than give them then try to answer it because you feel uncomfortable So that was my takeaway from what you did. And you had to do not answering something? Or maybe you don't give them the full answer. That is definitely not what you want. You know, I it in that moment. You had to present and you had to, you just think people value that over anything else, like being embarrassed? You know, that kind of thing? Right, right. And had to hold the fort you had no other option, no other alternative. So I'm sure the fact that you're thinking about it so many years later, probably more than a decade, or a couple

Ellyn Hassell: 1:01:04

Yes.

Zohra Mubeena-Mutabanna: 1:01:04

It stayed with you the lessons that you learn from that, that pivoting is important in our of decades later. profession.

Ellyn Hassell: 1:01:10

Absolutely. It's inevitable. It could be on a small scale, it can be on a large scale, but we're human. And that's going to happen, but I just believe in complete transparency. Yeah, be honest. That's one skill, or one, I guess, what do we call those? It's not a trait or virtue? I want to be nice, right? Yeah. In everything that you do. I just think that gives you so much more credibility than trying to kind of save face.

Zohra Mubeena-Mutabanna: 1:01:35

Credibility. That is how you build trust. Absolutely. And on that note, Ellyn, what a fantastic conversation!! I have really gotten this opportunity to pick your brains, though.

Ellyn Hassell: 1:01:47

It's been fantastic. I love talking about this material. I love helping other people. So I hope that your listeners have found some value in this and that they have some takeaways that they can apply to what they're doing. But selfishly, I've loved our one on one time together, just because I love talking to you.

Zohra Mubeena-Mutabanna: 1:02:05

Thank you. And I'm sure anybody listening to this will have many, many takeaways. You've taken us through this fantastic journey of what success for a writer can look like. And you're living that dream in a way.

Ellyn Hassell: 1:02:18

Oh, yeah. Well, it's been wonderful. And I've met so many great people along the way, people that I've learned from and that I've been able to teach. So yeah, I just think giving back and trying to mentor and help others as you grow in your field is invaluable. And it can be your successes and your struggles. I think as we've talked about here today, definitely some challenges and some and some successes, for sure.

Zohra Mubeena-Mutabanna: 1:02:41

Yes. The more struggles we have, the sweeter the successes, I believe.

Ellyn Hassell: 1:02:44

Yes, I agree. I agree. It's been such a pleasure Zohra. I'm. So I'm so excited. We did this. Yes, thank you.

Zohra Mubeena-Mutabanna: 1:02:51

Thank you so much, Ellyn. Subscribe to the podcast on your favorite app, such as Apple, Google, or Spotify. For the latest on my show, follow me on LinkedIn, Instagram, or visit us at www.insidetechcomm.show. Catch you on another episode.