Author: Benjamin Schwartz

Hi, I'm Ben! Growing up I wanted to be an astronaut because it looked fun. Then I watched Apollo 13 and saw that it was the engineers who had the most interesting and challenging roles. At Space Camp I learned about the unique challenges of living and working in space, so I decided to pursue a career in human factors engineering. I have been fortunate to work on many fascinating projects in aviation, military, and commercial systems. I'm proud to make complicated, mission-critical systems easier and more effective to use. I am currently the Director of Human Engineering at Monterey Technologies, a small business providing human engineering services to a variety of commercial and government customers. I support a top-notch team of human factors engineers, user experience designers, and other specialists. We apply agile, user-centered systems engineering to ensure that systems meet stakeholder and mission needs. I'm also involved in STEM education and mentorship through organizations such as the Society of Women Engineers (SWE), SAE International, Girl Scouts, and local schools. I'm passionate about improving the discipline and practice of systems engineering and particularly the systems engineering specialty of human systems integration (HSI). Through professional societies such as the International Council on Systems Engineering (INCOSE), the Human Factors and Ergonomics Society (HFES), and the National Defense Industrial Association (NDIA) I have contributed to the development of standards and guidance, presented at conferences, and generally shared my passion for developing mission-capable, highly-usable systems. That's also my objective for Engineering for Humans. Writing this blog helps me think through and organize my thoughts. I also want to bring awareness to the role of human engineering in system development and to foster critical discussion on current industry trends. I'd love to hear from you, you can reach me at benjamin@engineeringforhumans.com.

By Posted on

All models are wrong, some models are useful. George E. P. Box “Observe, Orient, Decide, Act” (OODA) is a simple decision-making model developed by US Air Force Colonel John Boyd. The concept is straightforward: Every entity in a competition is executing these four phases, the side that can execute them more quickly and accurately will win. “OODA” is a useful shorthand for discussing human decision-making and is commonly used in military circles. Of course, this simple phrase masks an enormous amount of complexity regarding the amount of information observed, the participant’s ability to orient, the quality of decision-making, and the …

OODA Loop: Observe, Orient, Decide, Act Read more »

By Posted on

The phrase “military-industrial complex” was coined by President Eisenhower in his farewell address to the nation in 1961. The United States has the most powerful military in the world, a fact that is extremely valuable to our nation and allies. Yet the influence of the military-industrial complex on our nation’s priorities and policymaking cannot be ignored.

Read more ›

By Posted on

I recently offered a mock interview to a high school student to help them practice and I realized I had a lot of advice to help students with the process. I searched online to see what advice was already out there and was pretty disappointed, so I decided to compile my own list.

Read more ›

By Posted on

The concept is simple: create a version of your solution that’s just good enough and put it out in the real world to validate assumptions about the product and market. That way, if your assumptions are wrong, you can pivot or shut it down without having spent too many resources on a failed idea. If your assumptions are right, you’ll have some great feedback to propel you along and help populate your product roadmap.

The term is often misapplied. Learn what an MVP is, what it isn’t, and how to leverage them for the success of your concept.

Read more ›

By Posted on

A common misconception is that Agile development processes are faster. I’ve heard this from leaders as a justification for adopting Agile processes and read it in proposals as a supposed differentiator. It’s not true. Nothing about Agile magically enable teams to architect, engineer, design, test, or validate any faster.

Read more ›