Techniques For Engaging Cross-Functional Engineering Teams

𝗛𝗼𝘄 𝘁𝗼 𝗕𝗿𝗲𝗮𝗸 𝗗𝗼𝘄𝗻 𝗦𝗶𝗹𝗼𝘀 𝗶𝗻 𝗠𝗲𝗱𝗧𝗲𝗰𝗵 𝗗𝗲𝘃𝗲𝗹𝗼𝗽𝗺𝗲𝗻𝘁: (𝗖𝗿𝗲𝗮𝘁𝗶𝗻𝗴 𝗰𝗿𝗼𝘀𝘀-𝗳𝘂𝗻𝗰𝘁𝗶𝗼𝗻𝗮𝗹 𝗵𝗮𝗿𝗺𝗼𝗻𝘆 𝘄𝗶𝘁𝗵𝗼𝘂𝘁 𝘁𝗵𝗲 𝗵𝗲𝗮𝗱𝗮𝗰𝗵𝗲𝘀) Ever notice how Quality, R&D, Regulatory and Marketing teams seem to speak completely different languages? This disconnect isn't just frustrating, it's costing your medical device company time, money, and potentially regulatory approval In my personal experience, I've seen how departmental friction can derail even the most promising innovations 𝗧𝗵𝗲 𝗥𝗲𝗮𝗹 𝗖𝗼𝘀𝘁 𝗼𝗳 𝗦𝗶𝗹𝗼𝘀 👉 Delayed submissions and market entry 👉 Regulatory surprises late in development 👉 Documentation rework and compliance gaps 👉 Increased development costs 👉 Team frustration and burnout Here's how to create seamless collaboration across your MedTech organization: 𝗦𝘁𝗲𝗽 𝟭: 𝗘𝘀𝘁𝗮𝗯𝗹𝗶𝘀𝗵 𝗖𝗿𝗼𝘀𝘀-𝗙𝘂𝗻𝗰𝘁𝗶𝗼𝗻𝗮𝗹 𝗚𝗼𝘃𝗲𝗿𝗻𝗮𝗻𝗰𝗲 Create a development council with representatives from Quality, Regulatory, R&D, Manufacturing, Marketing and Clinical. Meet bi-weekly with a structured agenda (top tip keep the minutes to use towards management reviews). 𝗘𝘅𝗮𝗺𝗽𝗹𝗲: A Class II device manufacturer implemented this model and reduced their development timeline by 30%, if not more, by identifying regulatory concerns during concept phase rather than pre-submission. 𝗦𝘁𝗲𝗽 𝟮: 𝗜𝗺𝗽𝗹𝗲𝗺𝗲𝗻𝘁 𝗦𝘁𝗮𝗴𝗲-𝗚𝗮𝘁𝗲 𝗥𝗲𝘃𝗶𝗲𝘄𝘀 𝘄𝗶𝘁𝗵 𝗔𝗹𝗹 𝗦𝘁𝗮𝗸𝗲𝗵𝗼𝗹𝗱𝗲𝗿𝘀 Don't move to the next development phase without formal sign-off from every department. This prevents costly backtracking 𝗘𝘅𝗮𝗺𝗽𝗹𝗲: During a stage-gate review (Design Review), a clinical specialist identified that the intended claims presented by the regulatory team would require further clinical data. By catching this early, the company adjusted their development plan rather than facing a surprise 6-month+ delay come submission time 𝗦𝘁𝗲𝗽 𝟯: 𝗖𝗿𝗲𝗮𝘁𝗲 𝗮 𝗦𝗵𝗮𝗿𝗲𝗱 𝗗𝗲𝘃𝗲𝗹𝗼𝗽𝗺𝗲𝗻𝘁 𝗟𝗮𝗻𝗴𝘂𝗮𝗴𝗲 Develop a glossary of terms that bridges departmental jargon. This prevents miscommunication that leads to rework. 𝗘𝘅𝗮𝗺𝗽𝗹𝗲: One client I worked with created a “MedTech Translation Guide” with input from each department. Not only did it reduce confusion, but it also built mutual respect engineers finally understood what the regulatory team meant by “intended use” and marketers stopped using terms that could trigger a knock on the door by Competent Authorities 𝗧𝗵𝗲 𝗕𝗼𝘁𝘁𝗼𝗺 𝗟𝗶𝗻𝗲? When this is done right, it accelerates development, strengthens compliance, and builds a more engaged team ✅ Faster to market ✅ Fewer compliance surprises ✅ Less internal friction If you're building your next-gen device and struggling with internal disconnects, it’s time to rethink how your teams work 𝘵𝘰𝘨𝘦𝘵𝘩𝘦𝘳 💬 I'd love to hear: How does your team keep cross-functional collaboration on track? #MedTech  #MedicalDevice #ProductDevelopment

Making Friends with Engineering: A GRC Professional's Guide to Speaking Their Language 🗣️ Want engineering to actually implement your security requirements? Start by speaking their language. Or keep getting ghosted. The traditional GRC-engineering relationship is basically a corporate cold war: - You request evidence - They pretend your email doesn't exist - You escalate to their manager (nuclear option) - They send screenshots with the enthusiasm of someone filing taxes - Both sides retreat to complain about each other in Slack - Repeat next quarter with fresh resentment Let's break this dysfunctional cycle 🔄 💡 Understanding Engineering Priorities & Workflows Engineering time is usually tied to product roadmaps, deadlines, and planned work. Whether they're using Plan->Build->Ship, Agile or "whatever works this week," one truth remains: unplanned security requests compete directly with product deliverables they've already committed to. When you drop a "quick request" that takes 3 hours, you're essentially asking them to sacrifice time that's already allocated—and possibly jeopardise commitments they've made to product leaders. That's like someone stealing your coffee every morning and wondering why you're irritated. Instead, try: - "Who manages your team's roadmap? I'd like to discuss including security requirements." - "What's your process for handling unplanned work?" (Translation: How can I not wreck your schedule?) - "Can we add compliance as a recurring item in your planning process?" (Translation: Let's make this predictable) 💬 Key Technical Terms That Build Credibility Nothing earns respect faster than showing you understand their world. It's like learning basic phrases before visiting another country, except the country is Linux and everyone's annoyed. Don't say: "Please take screenshots of access controls" Say: "Can we create an IAM role report using the AWS CLI?" Don't say: "We need to verify our website security" Say: "I'd like to review the WAF configuration and Content-Security-Policy headers" Don't say: "How do we know code is secure?" Say: "Where in your build pipeline are you running SAST and dependency scanning?" If you speak like that, you might be invited to their remote lunch. 🤝🏽 Collaboration Tools Meet them where they live, because they're not coming to your GRC castle: - Get a GitHub/GitLab account (bonus points: actually use it) - Learn to create issues with proper formatting (no walls of text) - Master the art of Markdown (the language for docs that doesn't look like it was written by a lawyer) - Use their ticketing system instead of yours (revolutionary concept) - Join their Slack channels (and laugh at their memes, even if you don't get them) The perfect compliance program that engineers hate is just an expensive screenshot collector. Stop being the GRC professional devs warn each other about in Slack and start being the security partner they tag when they need answers. #GRCEngineering

After years of managing rocky relationships between product and engineering leaders, these are the top 5 things I've learned you can do to make these partnerships great: 1. Foster Strategic Action: Maintain a well-thought-out backlog of problems that acknowledges potential risks and strategies for overcoming them. This approach keeps engineers engaged, solving real customer issues, and builds trust across teams. 2. Simplify Processes: Introduce only necessary processes and keep them straightforward. Maintain a regular schedule of essential meetings and minimize ad-hoc interruptions to give engineers more time to focus. 3. Collaborate on Solutions: Instead of dictating solutions, work closely with engineers to understand problems and explore solutions together. This partnership leverages their technical expertise and aligns efforts with customer needs, enhancing innovation and ownership. 4. Respect Technical Debt: Recognize and prioritize technical debt within the product roadmap. Trust engineers to identify critical technical issues that need addressing to keep the product competitive and maintain high-quality standards. 5. Build Relationships: Spend time with your engineering team outside of regular work tasks through meals, activities, or shared hobbies. Building personal connections fosters trust and improves collaboration, making it easier to tackle challenges together effectively. I’ve seen amazing product and engineering partnerships and some not-so-great ones. Teams that take the time to improve their relationship really see the benefits. While natural tensions exist, the best teams put in the effort to work well together, resulting in more successful products. #techleads #product #engineering

How Do You Connect People that Don’t Trust One Another❓ It happens – often. Relationships are fractured. Trust is low almost non existent between people. But avoiding each other is not an option. I recently had to do this amongst three cross functional teams as part of a broader organizational development initiative. Here’s how I responsibly and efficiently bridge fractured cross functional relationships. And got commitment from all parties from the beginning. 💡 Action 1 Created a clear plan/approach for making initial contact with each person. This was based on research, interviews and observations to understand the reality of the situation. 💡 Action 2 Connected one on one early in the project to understand more about their workplace reality and past experiences from a holistic perspective. 💡 Action 3 Understood early what each employee valued in their role and what their career plans were. Gaining an insight into each person’s motivating factors was key to shaping the focus and project approach. 💡 Action 4 Identified together where skill gaps existed in each person’s work practice and created a personalized L & D plan to respond to this. Co-designing this with each person was key to their buy in and ownership of the outcome and impact. 💡 Action 5 Acknowledged the challenges of past relationships with each person while clearly outlining the support I, and the broader organization would provide to make this experience positive.   💡Action 6 When the parties did come together I was clear on why it was key to work together differently across functions. How would it benefit them in their roles. And what they could expect from myself. 💡 Action 7 Had agreed outcomes and impact the team would deliver together. Checked in and measured progress weekly as a team with agendas that were shaped by each person.     What changes occurred as a result❓ ✳ Everyone knew what to expect from the interaction and had buy in.   ✳ People were acknowledging the support and wins of the other.   ✳ They were generously sharing intel and insights needed to deliver.   ✳ New knowledge and skill sets were developed from the experience that positively changed how they showed up and performed their role. Remember avoidance is not a long term option. How do you bridge the gaps between teams/people in your organization❔ Let me know your experiences and opinions below. 📚 I create original OD content to engage with, save and refer to later. Please follow or hit the 🔔 on my profile to get a practical and lived experience take on people, learning & growth, employee experience and organizational development. #organizationaldevelopment #leadership #culturechange #learninganddevelopment   *illustration courtesy of Yvette Pan

I watched our biggest initiative fail because of one critical mistake. We confused meetings with actual decision-making. More meetings feel like progress, but they rarely solve unclear ownership. When cross-functional projects start slipping, most leadership teams respond the same way: they schedule more alignment meetings. It feels productive. More discussion. More updates. More coordination. But the real problem usually isn’t communication. It’s unclear decision authority. When ownership isn’t designed clearly, meetings become a substitute for decisions. People talk more, but clarity doesn’t improve. Teams step on each other’s work. Deadlines slide. Every decision becomes a negotiation. The issue isn’t that people don’t talk enough. It’s that the system hasn’t defined who actually decides. When authority is distributed but accountability isn't, you get discussion instead of decisions. Strong leaders don’t solve this with more effort. They solve it with better structure. They design decision rights, not discussion forums. If cross-functional projects keep turning into long discussions instead of decisions, these 7 structures will help. 1️⃣ Map Decision Rights Before Projects Start Define who decides, who gives input, who gets informed. Test it before you start. 2️⃣ Distinguish "Consulted" from "Informed" Consulted = can change the decision. Informed = gets told the outcome. 3️⃣ Use the Commitment Test Ask: "What will you do differently?" Vague answers = you had a meeting, not alignment. 4️⃣ Institute the 48-Hour Decision Rule Cross-functional issues must be resolved or escalated within 48 hours. No exceptions. 5️⃣ Design Clear Escalation Triggers Define exactly when conflicts move up. Remove judgment calls. 6️⃣ Create the Autonomy Alignment Matrix Map decisions by impact vs. expertise. High expertise + low impact = full autonomy. 7️⃣ Set Response Time Standards Define response windows by decision type. Strategic: 5 days. Operational: 24 hours. Strong leadership reduces friction through structure, not effort. Design clarity into decision rights and authority. Alignment becomes automatic because teams know what they own, what they influence, and when to escalate. 💾 Save this for the next time your cross-functional projects turn into endless alignment meetings. ➕ Follow Rene Madden, ACC for systems-focused leadership strategies. Which of these decision structures would have the biggest impact in your organization?

Every time you draw an org chart, you're picking sides in battles that haven't started yet. That's just human wiring. Social identity theory shows people quickly form in-groups and out-groups, even on trivial distinctions. Any structure you choose will naturally create "us vs. them" dynamics. Without intentional design, you get the classic blame cycles: Sales says Marketing sends bad leads, Marketing says Sales doesn't follow up, and Engineering blames both teams for changing requirements mid-sprint. But you can architect your organization so those tribal instincts work for you instead of against you. Here's how: Design for the Work --------------------- ↳ Organize around the work. Map how value flows to the customer and align teams to that flow. Don't organize around internal convenience—and definitely don't design around specific people. Organize around the critical path from idea to customer value. ↳ Clarify decision authority. Ambiguity breeds conflict and delays. Be explicit about who decides, who's consulted, and who's informed. Unclear authority creates either turf wars or decision paralysis. ↳ Define cross-team handoffs. Wherever work passes between groups, nail down who owns what, what "done" looks like, and how problems get escalated. The real risk isn't within teams; it's in the transitions between them. Align the Incentives --------------------- ↳ Set common goals. Give cross-functional groups a small set of shared outcomes—revenue growth, customer retention, cost savings or any other collectively important target. Use cascading goals and KPI trees to show how individual work connects to the bigger picture. This keeps everyone pointed in the same direction instead of optimizing their own corner. ↳ Align rewards with cooperation. If bonuses are based only on silo performance, you'll get silo behavior. Shared metrics and joint outcomes encourage people to actually help each other succeed. Enable the Collaboration -------------------------- ↳ Support cross-functional work. Make sure teams have the data, tools, and forums needed to work together effectively. If those supports aren't intentional, collaboration erodes under daily pressures and competing priorities. You can't eliminate tribal instincts; they're hardwired. But you can architect your organization so those instincts work for you instead of against you. You probably can’t eliminate "us vs. them" entirely. But you can design so the structure channels natural group dynamics toward shared execution. #strategy #execution #orgdesign #teamwork

Designers and developers speak different languages. But when they listen early, magic happens. A few months ago, we kicked off a new product build. The usual setup: designers finalize flows, hand off to dev, then... endless Slack threads, clarifying questions, and "this isn't what I expected" moments. Sound familiar? This time, we took a different approach. Instead of working in silos, we brought everyone into the same (virtual) room—from day one. We ran cross-functional workshops: 👉 Designers walked through their thinking 👉 Developers flagged edge cases early 👉 Everyone had a say in feasibility before pixels were polished We used Figma’s handoff tools—not just as a delivery method, but as a shared language. And we held quick weekly syncs to stay aligned, not just at kickoff. The result? ✅ Build time dropped by 25% ✅ Fewer bugs ✅ Zero surprise revisions ✅ And... team morale? Way up. Here’s what I learned: When design and dev teams collaborate early, they don’t just move faster—they trust each other more. And that trust? That’s where the real magic starts. 👥 Tag a designer or developer you love working with. And share your best tip for making the collaboration smoother.

My client's teams weren't misaligned. They just never once asked what the other side needed to win. That one conversation changed how I think about cross-functional collaboration entirely. It's rarely about conflict. It's about structure, or the lack of it. Here are 6 things leaders can do to actually fix it: 1. Name a shared goal Default: Each team optimizes for its own metric. Reality: silos form around scorecards, not people. Try this: "What outcome do we all lose if this fails?" 2. Create a shared rhythm Default: teams operate on separate cadences. Reality: cross-functional work only happens when there's a crisis. Try this: one joint check-in, even monthly, changes the dynamic. 3. Clarify who decides what Default: everyone collaborates on everything. Reality: no one owns the call. Deadlock. Try this: "Who has final say, and by when?" 4. Surface the handoff gaps Default: each team finishes its part and moves on. Reality: things break in the white space between functions. Try this: "Where does ownership blur?" 5. Make tension visible early Default: protect the relationship, keep things smooth. Reality: misalignment goes underground and multiplies. Try this: "What are we not saying that matters?" 6. Ask what the other side needs Default: leaders only hear their own team's view. Reality: blind spots accumulate at the seams. Try this: "What does the other function actually need from us to succeed?" Cross-functional collaboration doesn't fail because people don't care. It fails because no one built the conditions for it to work. What would you add? Follow Shirley Braun , Ph.D., PCC for insights on building leadership capabilities in Tech and Biotech that scale without breaking. #Leadership #LeadershipTeams #collaboration #TechLeadership