Will Flores

Everyone hates reading the directions but that's because they're terrible. Out of date images, clunky language and faulty localization are rampant in Instructions for Use (IFUs). This drives me crazy because I always read the IFU. Every product I touch gets a best in class supporting document to make the user experience shine. But, that's only the tip of the iceberg. Usability forms perception, accessibility and outcomes. In countless ways, designers must consider human factors to give end users the superior results. Highly usable products break through crowded markets and define brand identity.

3

I was thinking last night. Why do I have this background anxiety. Some of it is I have to broad of experience. People keep wanting me to do embedded because I did electrical/embedded for a large part of my career. I started doing higher level software as my last company used less embedded devices. The low level skill set still came in handy for troubleshooting difficult software issues. Studying has kind of been a nightmare, trying to learn new skills and get newer certificates from what I am told is the need in the field. Also realizing those people are having a difficult time finding work. Then at the same time getting a few responses for embedded jobs. Which is a completely different area to study. As unemployment is starting to come to a close, I am starting to accept maybe I will have to take a job not in the field I committed my life too. I grew up in a poor area, joined the USMC to change my situation, paid for my college, spent massive amounts of time learning new technology as it came out, and a lot of late nights making sure we shipped products on schedule. Was it worth it? At times yes, at other times no. I think the transition came when corporations switched from building a real team vs people being expendable cogs. Despite the USMC being crazy at times we always worked as a team. Age has taught me to have gratitude for the right things. It has also pulled back the veil on what is truly important. Not what is programmed into us at a younger age.

14

1 Comment

Lately, I’ve noticed something strange: engineers—some of the brightest, most highly paid minds—are spending hours every week doing something that’s not engineering at all… They’re updating tasks in tools like Azure DevOps. Writing status updates. Moving sticky notes from “In Progress” to “Done” like it’s the most valuable part of their job. Let’s call it what it is: we’re doing project management cosplay. And it’s eating into real work. These tools make life easier for PMOs and leaders who want visibility without diving into the details. But to keep those dashboards glowing green, engineers are burning time that could be spent solving real problems. We’ve basically turned skilled professionals into part-time status administrators. Yes, visibility is important. But should it come at the cost of actual progress? Let’s ask ourselves: Are these tools supporting engineering or smothering it? Are we managing projects or managing perceptions? Here’s a wild idea: let engineers engineer. Disclaimer: These are my personal views and do not represent my employer. Unless my employer agrees, in which case… great!

23

4 Comments

One of the most liberating things I’ve learned in the workplace is this: Not everything is about you. The abrupt email. The silence in the meeting. The lack of response. The slightly cold tone. It’s easy to internalize these things, especially when you’re sensitive, self-aware, or deeply invested in your work. But the truth is, people are often moving through their own stress, burnout, and invisible storms. Taking a step back helps: 🟢 Was it actually personal? 🟢 Or was it projection? 🟢 Or maybe just a moment of pressure on their end? Emotional maturity is learning to pause before reacting and choosing peace over spirals. Today’s reminder: Protect your peace. Hold compassion for others, and for yourself. #EmotionalIntelligence #WorkplaceWellbeing #SelfAwareness #Leadership #PersonalGrowth

4

Great internal discussion today on "Architecting for Testability." Many will see that phrase and immediately react with yes! If you know, you know! The best system architects and software architects are considering test interfaces as they design. Have you ever encountered a system where it was difficult to do the tests you really wanted to do, and were stuck with system level, black box tests knowing that there were many states and conditions that would go untested? #highquality #riskmanagement #safety #fewerrecalls #softwarecpr

7

I really appreciate this breakdown in perspectives! "Conflict" within a Medical Device company should always be centered around what is best for the patient in the end. And diversity of thought and approach is what actually creates a safe environment for idea sharing and problem solving around a united goal.

14

1 Comment

This seems to be a comprehensive list of questions I’ve heard from both sides of the table when being an interviewee or interviewer. AI can help, but make sure it’s still “you” when you’re done. Be honest about your skills and wants.

1

An open question to those of you who work in the manufacturing space: who builds and maintains your internal data systems, and how well is that working for you? For better or worse I believe it would be uncontroversial to say in modern manufacturing that data and SPC are mandatory for any advanced competitive manufacturing, even in early development. If you cannot map product performance to manufacturing inputs and inspections you cannot fully understand your product or preempt/quickly respond to issues in the field. Above the controls level (SCADA, databases, message busses, etc) who defines and creates those systems? 1. Internal ITOT department 2. Manufacturing or R&D departments 3. External vendors I'd love to hear some thoughts on this, I've been thinking a lot lately about the disconnect between traditional software/IT folks and the people who traditionally produce and use the data (Engineers, Line users, and management). For our advanced manufacturing we build these systems in R&D while ITOT focuses on commercial data systems. Makes sense, a pilot manufacturing line has different needs and gets different support than your fixed high volume lines. We get to own the whole data chain and are much more agile for it. This arrangement, however, has drawbacks. Interoperability between commercial and R&D is a constant struggle. We don't get to leverage the larger organizational tech stack and infrastructure. The division of roles and responsibilities for equipment development can be blurry. But I only know what it's like from my perspective. I would love to learn from others about how internal data is handled. Is your data discoverable and easily configured? do your IT, Ops, and R&D people have solid hand-offs and communication? Do you have a clear path for data throughout the development lifecycle? Is your data system flexible enough to handle new product types, data sources, etc?

11

1 Comment

What would happen if you shipped tomorrow? No, really. Have you ever asked what would break if you tried? Would the hardware fail? Would the firmware crash? Would your documentation survive a reviewer’s skim? A lot of teams get stuck chasing tasks that feel important… …but aren’t the reason they can’t ship. When I join a project, this is the first question I ask. It's the question I was taught to ask over 15 years ago. It's the first question I've asked myself every morning for 15 years. And it's worked. I've shipped a lot of new products. Hundreds even. Because when you answer it honestly, something amazing happens: 🎯 You align your whole team around what actually matters. 🚀 You stop “looking busy” and start making real progress. ❤️ And you get closer to doing the thing that really counts - helping people. And often the answer is completely valid: ⚠️ Someone could get hurt. 🔩 The hardware isn’t ready. 🏭 We can’t manufacture at scale. All of these are good reasons not to ship. But they all raise the same, more important question: What are you going to do about it today? And if you really focused… could you fix it in a day? Would that mean you could ship tomorrow? As a design engineer, I’ve been called in at every stage from design early prototypes, to emergencies related to already fielded and legacy products. What they all have in common? Too many smart people spending time on the wrong things. Missing the forest for the trees. If you’re stuck in the weeds and the deadline’s not moving, try asking your team this: 👉 “What would stop us from shipping tomorrow?” The answer might surprise you. And it just might save your project.

1

The hardest shift from engineer → manager isn’t the title. It’s the mindset. As engineers, we’re trained to act tactically: fix today’s problem, keep the line running. As managers, we still need that presence — but we also need the strategic lens. Strategy isn’t mysterious. It’s simply: 1️⃣ Vision – the end state we want 2️⃣ Objectives – the outcomes that matter 3️⃣ Initiatives – the actions that get us there A strategic mindset doesn’t replace tactics. It guides them, so today’s actions actually move us toward tomorrow’s impact. 👉 How do you balance tactical urgency with strategic focus in your work? #Leadership #EngineeringLeadership #GrowthMindset #ProblemSolving #ContinuousLearning

73

4 Comments

Don’t pause your job search. The holidays may slow things down, but that’s your chance to stand out. If 25% of job seekers wait until January, that’s 25% less competition for you. Keep networking, researching, and building connections—you only need one good offer. Stay consistent. Stay visible. Stay determined. #opentowork

1

As 2025 comes to an end, I spent some time reflecting on what truly moved the needle for me as an engineering leader and people manager. Sharing my top 5 learnings, in case they resonate with others on a similar journey. 1️⃣ Focus and clarity beat volume This year reinforced that prioritizing a few high‑leverage initiatives with clear goals, owners, and success metrics creates far more impact than running many parallel projects or relying on heroics. Saying “no” (or “not now”) became a critical leadership skill to protect focus and quality. 2️⃣ Continuous feedback + psychological safety = performance The best outcomes came when feedback was frequent, specific, and behavior‑based—not just saved for formal reviews. Teams performed at a different level when it was safe to surface risks early, admit mistakes, and challenge decisions respectfully, without fear of blame. 3️⃣ Documented lessons turn experience into a compounding asset Retrospectives and “lessons learned” are only useful when they convert into concrete actions. Capturing what worked, what didn’t, and what we’ll do differently next time helped turn one team’s pain into the next team’s advantage and reduced repeat mistakes. 4️⃣ Relationships and communication are true force multipliers Strong relationships with stakeholders and cross‑functional partners often simplified decisions more than any process or framework. Proactive, transparent communication—especially during ambiguity and change—built trust in engineering as a strategic partner, not just an execution arm. 5️⃣ Scaling myself meant designing systems, not working harder Real growth came from shifting away from individual heroics toward better systems: clear rituals, decision mechanisms, ownership models, and simple guardrails. Coupled with regular self‑reflection on how I show up as a leader (energy, identity, and intent), this made the work more sustainable for both me and my teams. If you are an engineering leader or manager, would love to hear: 👉 What is one leadership lesson 2025 taught you that you want to carry into 2026?

31