From my personal experience, it can be difficult to bring up flaws to your lead, but I think that it is important to point out that there is issues early on as possible because if the project continues and the issue gets ignored for too long it may be too difficult to come up with a solution. Whenever I am in charge of designing a fixture, as soon as the design schematics are done, my boss and I will review them to make sure that it is a viable solution. It can be difficult to always understand issues that may come up, but it helps to note and solve as much of the issues from early on. However, I think that it is more important about how you choose to bring up the issue because it could put you in an awkward situation where your lead and you are tense with each other. Therefore, I think being mindful about how you point out the flaws is important and it helps to maybe bring it up privately first and see if there is a solution, but if you do not notice any changes then it is important to talk to someone higher up to make sure the issues gets solved especially if it is a dire situation. It is definitely a balancing act because you cannot simply force your thought onto someone in a dismissive manner, but it is important to acknowledge issues. More likely than not, the leads are going to be appreciative of you catching the mistake because it makes the later process smoother, which probably would have caused them more stress. 

From personal experience, there are a variety of ways to approach such a situation, especially when you need to work with other teams or departments; you almost need to speak different languages to different employees or managers. This is coming from someone who has worked in both functional and matrix organizations.

The project lead is typically the first point of contact when encountering any general issue in the project. This can include any concerns regarding deadlines, safety, financial, and so on; effectively, any issue that relates to the DDP and the PMP can be addressed directly to the lead. When I’ve spoken to senior engineers acting as project managers, they would usually have a good enough understanding of a specific area to have an opinion. However, the best PMs would also refer me to the individual/team responsible for a specific area of the project if more pertinent information or clarification is needed. If the chain of command was clearly defined within the DDP (which it was for our project), I would approach said individual with little difficulty, getting the answer(s) that I needed in their area of expertise. More importantly, I would learn something new that I could apply to my own responsibilities and enhance my experience.

I have been a part of experiences that have returned less straightforward results. In the functional organization I was in, I had asked about an SOP revision that would require a quality review before allowing my team to use a 3D printer for our project prototypes. The QA/Regulatory manager (we had a combined department) was unavailable, and the person in charge of reviewing SOPs was working through their backlog of other standards and procedures. Due to the organization being a functional one, the department was hard to get a hold of and was known to have a large silo, which prevented effective communication and caused me to be slightly afraid of escalating the issue.

The opposite was true about the matrix organization, where I’ve had similar issues resolved much quicker due to the staff member assigned to our project having greater dedication to our project as opposed to everything at once. This also eliminated the need for political pushing for accountability through functional management or higher, ensuring greater transparency and eliminating potential animosity.

As explained in the lecture and other replies, it's evident that matrix organizations have eliminated many of the barriers that functional organizations had by fostering a culture of involvement and collaboration. This gives us the ability to communicate any concerns we may have with much less difficulty than we would in a functional organization, which would cause a political rift and increase misinterpretation due to silos and their specific organizational perspectives. This holds within and outside our respective functions.

If I were in that position, I would first bring up the issue directly with the project lead, but I would do so in a cool, collected manner that emphasizes the danger rather than placing blame. If you are prepared with alternatives and a clear explanation of why the issue is important then hopefully a lead will respond favorably. However, if the lead rejects your concerns and you sincerely think there is a safety or regulatory risk, I'd say you have an ethical obligation as an engineer to escalate. Instead of using rumors or resentment, escalate through the appropriate channels like QA, regulatory, or a supervisor. Priority must be given to safeguarding both the product and the users.

The best approach to this is to raise the concern directly with the project lead while staying calm. Stating the clear facts and not placing blame is the most important thing that can be done. Bringing up ways to fix the issue and a clear explanation are things that can help with raising the concern in the conversation. If the issue is dismissed then escalation might be needed to for the sake of the safety of the project. Engineers have a responsibility to uphold safety and quality so making sure the project is safe is crucial. Staying silent could lead to bigger issues that could have been avoided.

I think that speaking up to a project lead depends greatly on how you phase what you want to say, instead of the content of what you want to say. Many things which require speaking up have valid foundations when referring to aspects which are technical, but the timing and phrasing matters significantly. In general, I learned that phrasing concerns in a matter which frames it around a shared goal is important to make sure the discussion is collaborative instead of adversarial. This is especially important if someone is new to a company. Many concerns should be solved in a collaborate manner, and this approach makes sure that the concerns lacks someone to blame directly, which can result in less confrontation and less organizational-politics issues. Of course, issues relating to safety and compliance is a different story because its an obligation to speak up, and leadership should respect this regardless of the concern.

I agree with the points raised by everyone so far. Addressing concerns to someone higher up is very daunting since relationships are at stake and you are in a lower position, possibly jeopardizing yourself. However, the stakes in medical device development are way too high to stay silent when you feel like something is off. Taking the first step to bring up the issue is extremely important to develop team dynamics and comfort level to deliver the safest and most effective product to patients. 

I want to talk more about the ethical responsibility of speaking about your concerns to higher-ups. Project management in medical device development requires balancing technical expertise and regulatory guidelines. This means that silence could cost costly recalls, fines, or harm to an individual. Thus, bringing up issues without putting blame is essential for ensuring the safety of all. To combat this silence, engineers can use data-driven arguments so it does not feel like blaming anyone, but it is just the raw evidence that there is an issue present. 

Documenting facts and potential consequences can be an effective way to raise concerns, since this documentation can speak for itself, and engineers can escalate issues to higher-ups without being too radical. It is more impactful and neutral to say “If we continue with this design, based on past data, we are looking at a 20% failure rate and regulatory fines” as opposed to “This design flaw is very dangerous.” With data, the escalation becomes more objective and less personal. These concerns can be raised with the project lead first and then escalated if the project lead is not cooperating. It is essential to ensure transparency. 

How do you think companies can create a supportive environment for engineers to use data and documentation to raise issues instead of having subjective opinions? Could this be part of a new training? Could AI be integrated to simulate the failure rate of devices to bring up potential issues to project managers?  

Something I think doesn’t get talked about enough is how much the environment affects whether someone actually feels comfortable speaking up. It’s not always about if we should raise the concern, but sometimes it’s about whether we get shut down if the concern is raised. Especially for newer engineers, that fear can be real.

I honestly think companies need to make it easier and more normal for people to bring things up. Things like regular risk-check meetings, discussions, or even a simple system where anyone can flag a potential issue without feeling like they’re calling someone out. When that’s part of the workflow, raising concerns doesn’t feel like starting a conflict.

Personally, I’d still go to the project lead first, but it’s way less scary when the culture already encourages questions and transparency. And if something actually needs to be escalated, it doesn’t feel like you’re going behind someone’s back, but feels like you’re helping the team avoid bigger problems later on.

So I think the solution is partly on the engineer, but also partly on leadership to create a space where speaking up is safe, normal, and expected. That’s what really makes a difference.

I think the optimal way to speak up about an issue or a flaw in a project is to push for a team meeting to address the issue while focusing solely on how to overcome the issue at hand. A full discussion would allow the team to brainstorm new solutions or alterations to the current flaw to minimize its impact. This could also be implemented with the other instances such as an unfair deadline or a risky decision. 

In a team setting, trust comes from communication between two people, and between a whole team. By setting up a meeting to address these issues without pointing fingers, individuals may feel more respected and may feel as though their contribution to the project is truly valued. If an issue is kept between one individual and a higher up, there isn't much room to grow and conversation/possible alternatives may be limited. The higher up may also be too busy to think of an issue at that moment. Assembling the team for discussion spreads the pressure equally between all members rather than confining it to just you and the manager and will allow further contributions and potential solutions to be found.