Podcast: Building Empathy and Accessibility: Fostering Better Engineering Cultures and Developer Experiences
2025-04-25T09:00:00Z
In this podcast, Shane Hastie, Lead Editor for Culture & Methods spoke to Erin Doyle about her journey as a generalist engineer, her passion for web accessibility, the importance of empathy and psychological safety in engineering teams, and her commitment to …
Transcript
Shane Hastie: Good day folks. This is Shane Hastie for the InfoQ Engineering Culture podcast. Today I’m sitting down with Erin Doyle. Erin, welcome. Thanks for taking the time to talk to us.
Erin Doyle: Thank you. Really excited to be here.
Shane Hastie: My normal starting point on these conversations is, who’s Erin?
Erin Doyle: I would describe myself as a generalist, a jack of all trades. I’ve done a lot over the course of my career. Started out at the Kennedy Space Center doing full stack development for the workers who would work on the space shuttle. After that, I did sort of product support, customer support, solutions engineering, which I wouldn’t say was my favorite job, but I learned a lot about troubleshooting, debugging, jumping into code that I didn’t write, and that was pretty valuable. After that, I did mobile development, which I was brand new to, and it was new to the company, so that was an exciting journey. And then I moved on to a full stack e-commerce team, and that’s when I really dove deep into web accessibility because that was a huge priority for the product, and had to learn all about that. And so then I got into talking and teaching workshops on web accessibility.
And then after that I did a little consultancy, which was another completely different experience, had to do everything, all the front, all the back, all the DevOps. And then eventually I moved over to a platform team. So, I’d done full stack development forever and then I got into platform development because I love the idea of supporting developers as my customers. I love doing the work to help enable my teammates, fellow developers to work more efficiently, effectively. And so I got to do a lot more of that over on the platform team. I got to wear a lot of hats, SRE, DevEx, DevProd, Ops, everything. So, now my final step in my journey, I just started a new job as a founding engineer at Quotient where we do development productivity software. So, that’s been a dream of mine. And of course as a founding engineer, I get to wear all the hats. The build-up of my career has led to this and I’m really excited about it.
Shane Hastie: Thank you. Let’s dig in first in one of those early passions, accessibility, web accessibility. Why does it matter so much?
Why accessibility matters [03:22]
Erin Doyle: Yes. It’s huge. And primarily it was huge to our customers at that company because we had a white label application for businesses, and these are businesses selling a product, and so, A, there was a lot of legal ramifications of websites that are trying to sell product. If they’re not accessible, people could sue for that. And we did have customers who had been sued for their own websites in the past, so it was a huge priority for them to be safe from legal action. But also if a customer can’t check out, if a customer can’t buy your product, you’re not making as much money.
Unfortunately, the bottom line for the business is maybe not altruistic, but that’s where it started. And once it started, and we could get into that, I could start talking to people about, we need to do this because we care, because accessibility matters to all of us. We should all have an equal experience using the web and mobile. It’s become our world. Everything we do is online. And so if we’re blocking people from being able to do the things they need to be able to do, the things they want to be able to do, that’s just not right. And so to care about our fellow human, we want to make these experiences equal and accessible. So, those are the big reasons why, legal, to make money, and because we care about our fellow humans.
Shane Hastie: What does good accessibility come down to?
Accessibility practices [04:57]
Erin Doyle: I think it’s really understanding your users, your audience and how they’re approaching your product. So, there’s a whole range of limitations. I’m not even going to just call them disabilities because sometimes it’s limitations. Sometimes it’s a temporary limitation that any of us could run into at any point in time. It could be environmental, it could be health related, whatever. It’s that many of us may approach using the web with some sort of limitation, whether it’s manual, meaning, we can’t use our hands in the same ways, maybe we can’t use a mouse, maybe we have dexterity issues, maybe it’s visual. We’re either blind or colorblind or just have impairment in your vision. Maybe it’s auditory, you can’t hear if there’s something that’s playing. So, there’s a lot of ways that people might be limited. We need to understand, based on those limitations, how are they using the web? How are they using computers? How are they using mobile devices? And then actually experiencing that.
I think really we have to try to put ourselves in their shoes as best we can and test out our applications using those same approaches that they might be using. Maybe it’s keyboard only. Maybe you can up the contrast. There’s lots of color contrast tools that maybe people who are colorblind might use. I’ve found issues where suddenly buttons on the page disappeared when the contrast was turned up on the site, and so people wouldn’t even know that those were there. Screen readers, every device has options of screen readers, and so actually using your site with a screen reader and/or keyboard only is quite a different experience. So, really approaching your site with all those and seeing, what is that user experience like and how do we need to modify it?
What are the things that we need to have the screen reader announce to people? Are there things that as the state of the page changes, we need to let them know that this thing is visible now? Or there’s an error, what is it and where is it? So, we need to just approach the user experience differently. And that’s why it really helps if you can get designers involved in this, so it’s not landing at the development stage. It’s sort of like, what is the user experience for someone using a screen reader? What is it for someone using a keyboard, etc. So, then we can develop matching those experiences.
Shane Hastie: There are guidelines. Are they useful?
Making sense of accessibility guidelines and tools [07:56]
Erin Doyle: It can be overwhelming. If you go to the various guidelines that are out there or if you look at the legal, well, and they vary by country. So, what the laws are in the US for accessibility are going to be different from the EU and so forth. So, approaching it from that direction can be really overwhelming. What are all the guidelines? How do I go through a checklist and make sure my site is doing all of these things? There are a lot of tools that help us, that can audit for the low hanging fruit, the things that are just easier to catch, not just statically, but even a runtime. We’ve got tools that you can run into the browser that as the state of the site changes, it can detect those things. But again, those are the really easier things to catch, so that you can at least start there.
I’ve always recommended taking a test-driven approach. Instead of starting with the guidelines and trying to make sure you’re matching them, start with a test-driven approach. Add the tools that are going to make your job a little easier, catch the low hanging fruit and have it tell you, this is inaccessible. And usually they’re really good at telling you why. You can get to more documentation that tells you why is this important? Why is this a problem? Here’s some recommendations on how to fix it. And so you can build up your knowledge set, bit by bit of, okay, these are the things we typically need to look for and these are the ways we typically fix them. And then you can create shared component libraries and things like that. So, you really only need to fix it once and it’s going to roll out to multiple places.
So, there are ways to help you be more efficient and get your arms around all these things to learn and make sure you’re doing. But after that, you really have to, like I said, you have to test the app. You have to find the rough edges of like, oh, this experience is terrible, or maybe technically this is accessible, but it’s really hard to do what I need to do, and then adjust that because we care about the user experience or we should. But you can go so far as auditors, there are many auditors out there that will test your site and will really go through the checklist and make sure you’re fully compliant. There are certifications out there you can get. But what’s tough is it’s a moving target. Every time you add a new feature, every time you make a change, you might inadvertently have just broken something about the accessibility of your site. So, it needs to be baked into the QA process as well to make sure you’re constantly testing and auditing for these things.
Shane Hastie: And as our styles of interaction change, so I’m thinking for many people today, the AI chatbot that’s becoming the core UI. How do we adapt to, as developers, how do we adapt to the new demands?
Adapting to new UI paradigms and accessibility challenges [11:15]
Erin Doyle: Yes. Again, we just have to be constantly testing, constantly learning and looking into those things. That’s a great point, is that this has become sort of a new UI paradigm that we’re running into a lot. And it may be that many of these chatbots, it’s one thing just to figure out, just to learn, how do I even add this AI chatbot? But then digging into making it accessible. So, we can’t just tack on these things and not continue to do our due diligence to make sure the experience is still accessible. Because if this is going to become the main way you interface with these products, you’ve just taken a site that might have been accessible for a lot of people and now added this huge barrier. It goes along with these overlays. I’m sure you’ve seen various websites that have this little icon somewhere at the bottom of the page and with some sort of accessibility icon on it.
And these overlay products really sell themselves as, we’re going to do all this for you, all you have to do is add this little thing to your code and we’re going to magically make it accessible. You don’t have to be an expert on accessibility, you just throw this in. And that’s really false. There are some ways that these overlays actually make things less accessible. Many of them add in their own screen reader, but it’s not as capable as the screen readers that are either built into the OS or that are natively available. So, they really don’t fix or make anything better. They actually hamper the accessibility. So, there’s no shortcuts. Just like everything else in software development, we have to learn our craft. We have to learn languages and frameworks and tools, and this should just really be one of the things that everybody, well, not everybody, front end developers, that just becomes part of your tool set, becomes part of your skill set.
Shane Hastie: Switching topics slightly, you made the point of your very wide experiences brought you to a state where you are comfortable now building products for engineers in that platform enablement, DevEx type space. What’s different when you are building products for engineers?
Building products for engineers [13:58]
Erin Doyle: Yes. First of all, what drew me there was empathy. I, firsthand, understand that experience when you have a workflow that’s painful, when you have friction in your day-to-day work, your feedback loops are slow or there’s just something awkward or annoying or painful or whatever, that you’re constantly being hampered and impeded and just doing the work that you need to do. I know how frustrating that is. I also know how hard it is to be on a product development team where you’re constantly under schedule pressure. We’ve got this feature we’ve got to get out, we’ve got this looming deadline, we don’t have time to go make this thing better or make this easier for us. So, we’re just going to put up with the pain, put up with these things that slow us down. We’re used to it, whatever. Maybe after the next feature launches, we can come back to it and make it better and that maybe in the future never happens.
And so I’ve experienced that over the years and I was always drawn to taking on those tasks of trying to make those things better for my team, so that my team members can stay heads down, focused on getting those features out, and I can try to help enable them to be more efficient. So, I’ve always felt passionate about that. So, when I had a chance to join a platform team, that was sort of my argument of, I know I don’t have a lot of experience in the Ops space or the DevOps space, I’ve got some, but I think I bring a perspective of what it’s like to be a product development engineer and what it’s like to deal with these things that are constantly getting in my way and what it’s like to work with a platform or DevOps team. What it’s like to be on the other side of the wall.
Understanding developer and platform team dynamics [15:50]
And so I was hoping to bring with that, this empathy, this understanding of the developer perspective. And there are all these stereotypes of when you’re on the dev side, you might be thinking, I really need help with this thing, but if I reach out to platform or DevOps, they’re going to think I’m stupid or they don’t have time. They’re so busy with all this stuff that they have to do, they don’t have time to help me with this thing. Or we speak different languages. They might be saying something that’s totally over my head and that might be a little intimidating. So, I have that. I understand what that’s like, and I have felt hampered in the past from collaborating or asking for help from the DevOps team or the platform team. So, jumping to the other side was really fascinating to see the perspective of the platform team working with developers, developers who are constantly being pushed and rushed and forced to cut corners and thus create problems that the platform team has to solve or SREs have to solve.
And so then there’s this stereotype of devs are lazy, devs are always cutting corners, devs don’t care about quality, or they don’t do their due diligence before they do a thing and they don’t want to collaborate with us. When we ask them to work with us to do something like database upgrades for instance, we need to work with them because they need to test their code to make sure it still works with the thing we’ve upgraded, but they don’t have time for this. They don’t make time for these kinds of things because it’s not on their product roadmap. So, I saw both sides of how we see each other over the wall, but having empathy for what it’s like to actually be in the shoes of either side was super powerful for me. And I was able to explain to my teammates, I know we think that maybe the devs are being lazy or maybe they should know more about this thing that we’re having to help them with, but they don’t have time.
Cognitive load and shifting responsibilities in development [18:06]
They’re taking on such a high cognitive load, especially these days as we’ve added so much in the cloud, as we’ve added so much tooling. We’ve got so many products, we’ve got so many options now and we’ve shifted left so much. The DevOps movement shifted a lot left to developers. The, you build it, you run it. Developers have to be responsible for a lot, a lot of infrastructure, a lot of architectural decisions, security, even as we just spoke about web accessibility. We’ve put a lot on their plates. So, in order to continue to meet their deadlines, they are forced to cut corners. They aren’t able to learn how to use every tool and how to really be knowledgeable about everything in the landscape. So, to explain that to my platform team members of like, we’ve got to keep in mind the context here of what they’re dealing with.
And then on the other end, how can we as a platform team change how we are seeing or interpreted by the developers, so that when they do need help, they’ll ask for it. So, they’re comfortable asking for the help they need. When they have to reach into this space of creating new infrastructure for the feature they need or getting the right amount of observability on some new feature, when they need that help, we need to be approachable, we need to be available or else they’re going to do it on their own. Again, going back to the DevOps movement, we have this concept of devs should just be able to do it all on their own in order to move quickly, but that’s asking too much these days. And so I really wanted to promote this idea of, we can meet you where you’re at. The platform team can stretch over the aisle and meet you where you’re at.
And so if you don’t know how to use these tools, if you’re not knowledgeable about the various infrastructure options available these days, let’s collaborate on it. Let’s work on the architectural design together. Bring us in as a partner, so that we can help you do these things to get that feature ready for production. Instead of the developer shouldering it all and not doing as good a job of it because they’re in an area they’re not experienced in. They’re doing their best, but if they don’t have that deep experience, they’re going to make mistakes, they’re going to miss things. And when they miss, it becomes the platform team or the SRE team’s problem later.
We’re going to have to fix that problem that blows up in production way down the road, or we’re going to find that we’re totally missing observability about something and maybe we have errors or we have problems that we don’t even know are happening or we’re not scaling appropriately. There’s so many outcomes based on just that interaction of devs trying to do more than they really are experienced or set up for success to do, and not feeling comfortable asking for help or collaborating with the platform team. So, building psychological safety, where they feel comfortable, they feel safe, they don’t feel judged, being able to reach out and say, “I really need help with this aspect of this feature I’m working on”.
Shane Hastie: Psychological safety, an incredibly important concept that’s become a buzzword. What does it really mean to create a safe environment where people can ask those slightly embarrassing questions or difficult questions?
Fostering psychological safety and collaboration [22:04]
Erin Doyle: Yes. I found that the more I learn about psychological safety, the more I start to see it everywhere, and I start to see that sort of chain reaction or root cause analysis on negative outcomes being the result of a lack of psychological safety. And it can be complex. It can be subtle because we’re humans. We’re humans interacting with other humans, and we’re all approaching those interactions with preconceived notions and whatever our histories are, whatever our psychological issues are. So, it’s complicated. But I’ve really found, and it’s been hard for me, that the more that I can model vulnerability myself, and especially as I’ve become more senior over the years, the more that I can show that there are things I don’t know or there are mistakes that I make, there’s questions I have, the more I hope I’m creating this environment for other people to feel like they can do the same.
As I was earlier on in my career, as I was just starting to become more senior, I felt a ton of pressure to prove myself, to prove that I deserved the role, and that created a lot of bad behavior. I was a perfectionist. I was a workaholic. If there was something I didn’t know, I couldn’t admit it, and I couldn’t ask for help because then people would know that I didn’t know everything and I wasn’t the best. So, it was really hard to take on all that pressure of like, “Oh, jeez, I don’t know this thing, but I don’t want anybody to know that I don’t know”. So, now I’m going to work extra hours. I’m going to work all weekend to learn this thing and try to present myself as if I knew it all along, and that’s really unhealthy.
And as sort of a negative side effect, I created this model, or I set this bar to my teammates that they had to be perfect too. When I never made any mistakes, I always knew everything, I had all the answers, then they felt, especially the more junior people, they thought like, “Oh, this is the standard, and so I too can’t ask questions. I too can’t ask for help because I guess we don’t do that here”. And so I created a really toxic environment around myself without realizing it. And so as I got a little more senior, a little more experienced, and I finally started hearing people talking about this, I think that’s another thing that’s changed a lot over the years, as more people talk about culture, as more people talk about psychology and working together, the more I was hearing things about psychological safety and how we can impact others with our behavior when we’re not cognizant about the model we’re setting for others.
So, it was really hard for me to go from that perfectionist, I have to be perfect, I have to prove myself to what I have to make mistakes. I have to show people that I don’t know everything, if I want them to feel comfortable working with me, if I want us to be able to collaborate. And I did see examples of where maybe I didn’t make the environment comfortable for others, and I knew that they had questions or I knew that they had things they wanted to say that I’d find out later, that they didn’t say to me or they didn’t ask me. And so I realized, oh, I’m not making people feel comfortable approaching me or being open with me with their thoughts or disagreeing with me. That’s a big thing.
If I don’t make the environment comfortable for people to feel like they can offer an alternate view of something, if I make a statement, if I pose a thought, if I do that in a way that’s too assertive, it could cause other people to feel like, “Oh, well, she must know better than I do”. Or “If I offer this contrary viewpoint, I’m going to sound stupid”. Whatever it may be, whatever that fear is that they’re having in their mind, I’m now not going to hear that alternate viewpoint. I might be wrong. I’m wrong all the time. Maybe there’s just some aspect of this that I’m missing or something that I don’t have personal experience with. And so if I’m shutting off that opportunity to hear that, maybe that was a better idea than what I had, maybe they thought of something that I didn’t and I missed. And so we’re so much better off when we can make people feel comfortable saying, “Oh, well what about this?” Or “Have you thought about that?” Without fear of, I don’t know, it being taken personally, it feeling like conflict.
So, somehow we have to create that environment where it’s not personal, it’s just normal. We can have discourse and it’s comfortable and it’s normal, and it’s how we do our work. But again, you have to sort of plant the seeds. You have to lay the foundation, and that comes from senior people modeling that behavior. Really, I noticed it as I was gaining experience when I would see those people that I looked up to, that I thought were really smart, talented, when I saw that they weren’t perfect, that there was things that they didn’t know and they felt comfortable, they weren’t ashamed, they weren’t apologetic, they were just like, “Hey, I’ve got this question”, or, “Oh, I just broke this thing in prod and just so you know, I’m fixing it”. But it’s not apologetic. It’s not scraping. It’s not, “Oh, I’m so sorry I broke prod. I’m so embarrassed”. We don’t have to be embarrassed. We make mistakes.
And so when you’ve got that attitude of like, “Yes. I made this mistake just FYI. I’m working on it”. It really lowers that barrier for us all to be open about like, “Yep. I made this mistake. Here’s what we’re going to do about it”. Or “I could use some help. I missed this thing”, or “I’m not really knowledgeable about this area that I’m working in, maybe someone else is, maybe they can help me”. And so the more we can just make that normal part of just how we work, the more we can allow space for all those things that if we didn’t have, we’re not doing our best work.
Shane Hastie: Being vulnerable, leading by example. It’s hard.
Modeling vulnerability and leading by example [28:36]
Erin Doyle: Yes. It’s really hard. I almost equate it to, I don’t know if you’ve ever jumped off something high up, jumped off into the water or, well, I guess you’d usually be jumping into water, but if you’ve ever taken a leap, I have a fear of heights, so that’s really scary for me. I’m never going to go skydiving or bungee jumping, but those concepts of, I’m going to take a leap and I have to believe that I’m going to be fine. It’s just this scary little thing that I have to get over, but the belief that I’m going to be fine is what pushes me to take that step. I feel that way all the time. I still to this day feel that way all the time. I’ll have a question or a problem or whatever, and I’ll pause and I’ll think, if I ask this, maybe I’ll sound stupid, this could be embarrassing, whatever.
I still have those thoughts, but then I just remind myself of that’s okay, you know that this is okay, and you know that showing this little bit of vulnerability on a regular basis is going to help someone else. So, that’s what kind of helps me take that leap.
Shane Hastie: I’ve learnt a lot of really good insights and good advice in there. If people want to continue the conversation, where can they find you?
Erin Doyle: Yes. The easiest place is probably LinkedIn. I’m on there. And I do have my own website. It’s got a few blog pages on it, unfortunately not as many as I’d like. And it’s also got whatever talks I’ve done or articles I’ve been featured, whatever I’m doing out in the community is listed there. And that’s just erindoyle.dev.
Shane Hastie: Thank you so much for taking the time to talk to us.
Erin Doyle: Thanks. It’s been a lot of fun.
Mentioned:
Erin Doyle on LinkedIn
Auto-posted from news source
About The Author
