# Anna J McDougall Stories by Anna J McDougall on Medium This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Engineering Audits for ISO 13485 Medical Device Software Quality Management Systems DevFeed: [Engineering Audits for ISO 13485 Medical Device Software Quality Management Systems]() Original publisher: [Read original article]() Author: Anna J McDougall Published: 2025-08-18T20:21:35Z Content type: article Language: en Sources: [Anna J McDougall]() Topics: [audit](), [Requirements](), [Development](), [Software](), [systems]() Tags: [audit](), [coding-style](), [compliance](), [engineering](), [engineering-management](), [iso](), [iso-13485-standard](), [lifecycle](), [management](), [medical-devices](), [processes](), [quality](), [regulatory](), [requirements](), [review](), [risk-management](), [safety](), [software](), [software-engineering](), [systems]() ### AI overview This case study explains what an engineering audit involves under ISO 13485 for medical device software. It covers Quality Management System documentation, lifecycle management, patient safety, risk management, regulatory requirements, and the author's experience updating engineering compliance documents. ### Source excerpt What is an Engineering Audit Like? An ISO 13485 Medical Device Engineering QMS Case StudyI think I found my new look. If there's one thing that gets me fired up, it's a good ol'-fashioned audit! ... Said nobody ever. Sadly, audits are a part of the business world that tend not to be fun. However, they also serve an important purpose, and are part of the transition from the "fun team lead" style of management into the "business leader" role is coming to grips with the unsexy stuff. As part of my role at HelloBetter, I was tasked with leading engineering compliance and reporting for ISO 13485, an internationally recognised standard for Quality Management Systems (QMS) specifically for medical device manufacturers, within the broader context of the EU Medical Device Regulation (MDR). For those who aren't familiar with what an audit of this kind involves, the simple version is this: Certain requirements exist as part of the standard, not just about how to effectively create and maintain software, but also how to document that compliance. This documentation is referred to as the Quality Management System (QMS), which as the name implies serves as documentation for how you maintain quality as per the ISO. The ISO isn't only about software, but software is part of "Lifecycle Management", tracking how a medical device (in this case) goes from design and development to distribution and surveillance. A company required to meet the ISO should therefore create and follow a system that ticks all the boxes for things like patient safety, risk management, and any additional regulatory hurdles. Typically once a year, an auditor is hired to enter the company and review the documentation alongside representatives from the company who guide them through the QMS. Additionally, individuals (like me!) are pulled from different parts of the company to talk through their processes and documentation, and to show any examples that may be relevant. My Experience with Engineering Compliance for ## Explain Less, Align More: Explaining tech to non-technical stakeholders DevFeed: [Explain Less, Align More: Explaining tech to non-technical stakeholders]() Original publisher: [Read original article]() Author: Anna J McDougall Published: 2025-07-22T16:33:29Z Content type: opinion Language: en Sources: [Anna J McDougall]() Topics: [Architecture & Design](), [Microservice](), [implementation]() Tags: [communication](), [digital-transformation](), [engineering-management](), [implementation](), [information-technology](), [microservices](), [software-engineering](), [tech](), [technical](), [technology]() ### AI overview An article presents communication strategies for explaining technology to non-technical stakeholders and reducing resistance to digital transformation. It recommends adapting language to the audience, establishing expectations, avoiding assumptions about understanding, and starting with simple explanations. ### Source excerpt Introduction A few months ago, I was invited to speak on behalf of the women's tech organization AnitaB at a Deutsche Bank event. The topic was "Communication Strategies for Overcoming Stakeholder Resistance to Digital Transformation." It might sound a bit like buzzword salad, but it's actually a crucial skill for technologists, especially in cultures where change is often met with resistance. Anyone working in German digitalisation will recognise the familiar phrase: "It's always been done that way." Unfortunately, just before the event, I came down with Norovirus (which, by the way, I do not recommend) and had to withdraw from the talk. While a blogpost can never replace the energy of a live presentation, I wanted to share some of the key takeaways here. You can also access the slides of the presentation I prepared here. Main TakeawaysSpeak their language Are they in business, marketing, or finance? Rather than jumping into technical jargon, take time to consider which terms and concepts they're likely familiar with. And if you're not sure, ask. For example: "If I say 'microservices', is that familiar enough for you to explain back to me, or would you rather I go over it?" or even don't ask and default to "Unless anyone objects, I'm going to do a quick refresher on what a microservice is". An important note here is not to ask questions where people default to a false yes. For example, you want to avoid "You get that, right?" or "That's familiar to you already, I assume?". Asking these questions makes it hard for any individual to lose face and voluntarily say "Actually no, I'm the person who has no clue about this". Establishing expectations also helps: the stakeholders might be asking more about budget or people than about the details of the technical implementation at all! Your refresher on microservices might be totally out of place is you don't establish early that that's what the conversation is actually about. My tip here is to start simple, and work your wa ## Taking Ownership and Handling Difficult Responsibilities as an Engineering Manager DevFeed: [Taking Ownership and Handling Difficult Responsibilities as an Engineering Manager]() Original publisher: [Read original article]() Author: Anna J McDougall Published: 2025-06-25T12:20:24Z Content type: opinion Language: en Sources: [Anna J McDougall]() Topics: [engineering-leadership](), [Development]() Tags: [engineering](), [engineering-leadership](), [engineering-management](), [engineering-manager](), [leadership](), [leadership-team](), [management](), [management-skills](), [software-engineering](), [teams]() ### AI overview This commentary argues that engineering managers must sometimes accept conflict and deliver difficult feedback instead of trying to remain peers with their teams. As leaders move away from hands-on development, they must balance engineers' needs with stakeholders, product, and business expectations. ### Source excerpt An Engineering Manager's Guide to Taking Ownership by Taking Heat Title Image: a vibrant yellow background with a picture of Anna smiling, with two red devil-horns superimposed on top. Title text reads: "It's time to be the BAD GUY. An Engineering Manager's Guide to Taking Ownership by Taking Heat"Introduction At my first project management job, I was given the nickname "Mad Dog".* Any time new sales reps would join the company, the existing reps would try to scare them by telling them "Oh shit, you're on Mad Dog's project". The joke, of course, is that I'm a big ol' ray of sunshine: After a few days of being scared to encounter Mad Dog, those reps would meet me and realise they weren't going to have a problem with some hard-ass micromanager. The same is still true today, but I've also come to realise that there are some benefits to being Mad Dog. Sometimes, the best way to help your team is to lean into being the bad guy. In this post, I'll cover some situations where it's good to be bad, and why being the bad guy is a core management skill. * The nickname came about due to my name's similarity to a famous football player (Adam "Mad Dog" MacDougall). Say "Anna McDougall" and "Adam MacDougall" ten times and you'll hear it. Leadership means stepping out of the team As you move up the engineering leadership chain, from EM to Director to VP to CTO, you become less and less a part of the development teams. This sense of social isolation often drives leaders to try their best to be buddy-buddy with developers, to attempt to completely eradicate any sense of hierarchy, and to improve psychological safety. In general, this is a great idea. As a leader, you do need people to know that you're just human. You should have people trust you with their real thoughts. You must enable a culture where failure and feedback are freely given and learned from. But... You are also the one who has to take the heat from above, and sometimes you have to be the bad guy to the team when it come ## From ePA 2.6 to 3.0 : Healthcare Data Integration for Electronic Patient Records at HelloBetter DevFeed: [From ePA 2.6 to 3.0 : Healthcare Data Integration for Electronic Patient Records at HelloBetter]() Original publisher: [Read original article]() Author: Anna J McDougall Published: 2025-05-20T09:27:30Z Content type: tutorial Language: en Sources: [Anna J McDougall]() Topics: [data](), [implementation](), [Authentication](), [Back end](), [Front end](), [XML](), [pdf]() Tags: [authentication](), [backend](), [data](), [electronic-patient-record](), [engineering-management](), [export](), [frontend](), [germany](), [healthcare](), [healthtech](), [integration](), [pdf](), [pipeline](), [platform](), [product](), [project](), [software-architecture](), [technical](), [terminal]() ### AI overview This technical post describes HelloBetter's implementation journey from Germany's ePA 2.6 to ePA 3.0. It covers HealthID login, ePA data export, PDF and XML document writing, and the frontend and backend integrations used to connect therapeutic data across systems. The implementation was completed pending BfArm approval. ### Source excerpt From ePA 2.6 to 3.0: A Technical Journey in Healthcare Data Integration for Electronic Patient Records...so far Germany has a bad reputation for digitalisation, so the government's push to implement an electronic patient record ("elektronische Patientenakte" or ePA) for its citizens and residents is a step in the right direction. As an official digital health application ("digitale Gesundheitsapplikation" or "DiGA"), we are obligated to shift to the ePA 3.0 implementation. The government rollout has been plagued with technical difficulties and delays, but we're now at a point where we have completed our implementation successfully, pending BfArm approval. In this post, I want to cover the exact steps we and had to take to achieve this. I want to thank Senior Product Manager Tanja Lembcke and Senior Backend Engineer Chaythanya Sivakumar for their contributions to this piece. The Challenge: Connecting Patient Data Across Systems The electronic patient record (ePA) and HealthID integration project had a clear mission: we wanted to give our patients the ability to log into the HelloBetter platform using their HealthID (which they access through their insurance company) and export their HelloBetter data into their ePA. A successful implementation would mean that both doctors and patients can electronically access therapeutic data whenever they need it. To make this happen for the patient data at HelloBetter, we partnered with two key players: RISE for ePA system access and Azuma for HealthID system access. Our journey began in 2024 when our backend team laid the groundwork for ePA 2.6, setting up the pipeline and data export in our staging environment. We successfully implemented both PDF and XML document writing capabilities, along with the frontend and backend integrations for HealthID login. How It All Works: The Architectural SideHealthID Authentication The first piece of the puzzle is connecting to and authorising the user's HealthID. This part of the system has remai ## EM/PM Relationships Aren't About Luck: 5 Tips for Product/Tech DevFeed: [EM/PM Relationships Aren't About Luck: 5 Tips for Product/Tech]() Original publisher: [Read original article]() Author: Anna J McDougall Published: 2025-05-13T14:53:24Z Content type: opinion Language: en Sources: [Anna J McDougall]() Topics: [Code quality]() Tags: [code-quality](), [compliance](), [engineering-management](), [engineering-manager](), [engineering-mangement](), [identifier](), [improvements](), [iso](), [management](), [product-engineering](), [product-management](), [quality](), [relationships](), [team-lead](), [teams](), [tech-leadership]() ### AI overview An opinion article presents practices for building effective engineering manager and product manager relationships. It emphasizes shared ownership across business, team, and product goals, with quality improvements--including compliance work--as part of an engineering manager's contribution. ### Source excerpt EM/PM Relationships Aren't About Luck: 5 Tips for Product/Tech TeamsHeader image: purple background with the text "EM/PM Relationships Aren't About Luck. 5 Tips for Product/Tech Teams :)" and a photo of Anna and Tanja together.Introduction As my probation period at HelloBetter was coming to an end, my team's Senior Product Manager Tanja Lembcke remarked, "It's great working with an EM who cares so much about product." I could easily have said the same back to her, because it's just as valuable working with a PM who cares deeply about technology, something at which she truly excels. Together, we've become a strong team. Much of that relationship has developed naturally, but I've also noticed a few intentional practices that have helped us along the way. I want to share them here for all the product managers, engineering managers, and whoever else happens to like reading my sporadic blog posts. In the end, Tanja and I didn't just "luck out" working together. There are some tried-and-true strategies we both employ to make the most out of our work and get the results we need. If you prefer LinkedIn, you can view the short-form version of this post as a summary and carousel here. Tip 1: Purposefully be the intersection of business, team, and product As a Team Lead or Engineering Manager, it's important to operate at the intersection of business goals, the engineering team, and product. This means not only using the product but also critiquing it, asking thoughtful questions, and continually returning to the core "Why." It is all too easy to sit back and just wait for features to drop in your lap, estimate them, deliver them, and then dust off your hands with a "job well done" attitude that allows you to add a nice dot-point to your CV about value creation. What is much harder, is to actually focus on quality: that hard-to-measure, hard-to-prove value that is constantly competing with your time. For EMs, we tend to see the word "quality" and jump to the concept of code qu ## Rethinking Technical Interviews for Virtual Hiring and AI-Assisted Candidates DevFeed: [Rethinking Technical Interviews for Virtual Hiring and AI-Assisted Candidates]() Original publisher: [Read original article]() Author: Anna J McDougall Published: 2025-04-17T19:08:54Z Content type: opinion Language: en Sources: [Anna J McDougall]() Topics: [Tech Careers](), [Artificial Intelligence](), [LeetCode](), [Algorithms]() Tags: [ai](), [algorithms](), [artificial-intelligence](), [careers](), [chatgpt](), [engineering-management](), [interview](), [interviewing](), [software-development](), [technical-interview](), [technology]() ### AI overview This opinion article argues that virtual hiring and AI tools have exposed weaknesses in traditional technical interviews. It discusses limitations and equity concerns associated with algorithm assessments and take-home projects, and introduces the McDougall Method at HelloBetter as a proposed response. ### Source excerpt Building the McDougall Method at HelloBetter: A Fairer, More Modern Approach to Technical Interviews As someone obsessed with tech careers, business growth, and engineering management, I am constantly coming up against the boogey-man of technical interviews. In many ways, tech companies are stuck in the thinking of 20-30 years ago: white boards, algorithms, logic puzzles, and tasks that rotated around an in-person interview space. We're in a new era, where 99% of engineering interviews are done virtually and the candidate's workspace is uncontrollable by the interviewing team. We need to adapt to this, not by simply porting previous methods across to an online platform, but by fundamentally rethinking the skills we expect 21st century software engineers to have. Naturally, opinions about what is wrong with technical interviews are prevalent both from employers and (potential) employees. For example, leetcode-style assessments have long been derided as being a bad test of abilities. "Instead," opponents argue, "you should use take-home tests or projects that the candidate can explain back to you". Ah, but you see, not everyone can afford to let their evenings and weekends disappear into these take-home tests or side projects. Due to this inconveniently linear construct called "time", more experienced engineers start having or caring for families, adopting pets, or (lord forbid) doing sports and hobbies. It's also no big secret that the majority of housework and care duties still tend to be shouldered by women. To put your best foot forward as a candidate, you will create the best possible solution, no matter how many hiring managers tell you to "only spend 2-3 hours on a solution". Therefore, take-home or "own project" technical interviews tend to put older candidates and women candidates at a disadvantage. One other problem popping up nowadays is the prevalence of AI tools for engineers to pass technical interviews, ranging from manually entering prompts into ChatGP ## How to Support Junior Developers: Ten Crucial Tips for Seniors and Leads DevFeed: [How to Support Junior Developers: Ten Crucial Tips for Seniors and Leads]() Original publisher: [Read original article]() Author: Anna J McDougall Published: 2021-06-13T20:15:51Z Content type: article Language: en Sources: [Anna J McDougall]() Topics: [Learning](), [Tech Lead](), [Development](), [Java](), [Testing](), [Microservice](), [Docker]() Tags: [careers](), [communication](), [docker](), [how-to](), [java](), [junior-developer](), [junior-developers](), [leadership](), [mentorship](), [microservices](), [senior-developer](), [tech-lead](), [testing](), [tips]() ### AI overview A junior software engineer who is temporarily filling in for a Tech Lead shares ten tips for supporting junior developers. The article emphasizes communication, clear expectations and timelines, structured learning, and realistic expectations about early performance. ### Source excerpt Introduction I am in a unique position right now: I am a Junior Software Engineer filling in for a Tech Lead for two weeks, covering two internal projects filled with other juniors, trainees, and interns. This means that I am both a junior and acting as a guide for juniors at the same time. This isn't the first time I've played this 'double role': when I was completing my year-long training in web development, I was both a student and a class tutor: learning and teaching at the same time. There is a lot to be said for this: namely, that teaching helps you learn as well. Additionally, this unique position allows me to provide insight on how best to support junior developers with the advantage of both perspectives: that of the junior, and that of the supporter. All that said, let's talk about ten things you can start doing to better support your juniors today. Spoiler alert: a lot of it comes down to communication! Follow Me on Twitter @AnnaJMcDougall1. Define expectations and timelines It can be extremely disorienting to enter not only a new workplace but also a new industry. If you are in charge of guiding the path of a junior, it is your job to explain to them as early as possible what that path will be, what is expected of them, and what kind of timeline they'll be working with. "For the first month or so, you and I will be working closely to have you trained up in Java for the backend, including testing and basic microservices. There is no set timeline for this, but once you feel you're ready to move on, we'll then look into Docker and other containerisation technologies. The goal is that by about six months into your time with us, you'll be comfortable and confident coding the backend for bigger projects." Alternatively, you could speak more broadly: "As a junior, we really want you to focus on learning and asking as many questions as possible. You'll have a chance to explore a lot of different technologies, and after around a year we can talk more about which y