September 2013. That was the date I accepted an offer for a Maintenance and Reliability Engineer role in one of the largest oil and gas service companies in the world. I had no clue what the role really meant. Since it was about industrial equipment, I thought, I am a Mechanical Engineer, I will figure it out.

Later I realized it was not only me who did not know what reliability engineers do. More or less all my stakeholders, including my manager, were not very clear about it either. So, I had to learn on my own, and later find ways to add value to the business.

What you will get out of this article?

If you are a fresh graduate engineer looking to build a career in reliability engineering, or a company unsure about what type of engineering service to seek or who to hire to improve product or process reliability, you are in the right place.

By spending just 10 minutes reading this article, you will learn:

• What reliability engineering really is
• The different reliability engineering roles
• The key skill sets required for each role

What Reliability Engineering Really Is

At its core, reliability engineering is about ensuring that things work consistently, safely, and cost-effectively, for as long as they are intended to, under the environmental and operational conditions they will face.

If your Toyota Corolla runs for years without failing as long as you maintain it, if your phone survives a few accidental drops, or if your asset in a factory keeps producing quality products day after day, that is RELIABILITY.

I usually write articles about topics I personally struggled to understand from the sources available to us such as books, online resources, and so on. I believe most technical concepts are fairly straightforward at their core, but the way we express ideas and translate our understanding into writing often makes them harder for others to grasp. That’s an area where we can all continue to improve.

As part of that journey, my goal with the Breaking Bad for Reliability newsletter is to be a communicator of Reliability Engineering principles, and I am doing this mainly for two categories of people:

• People who want to become reliability engineers but have minimal information about their responsibilities.
• People or companies who want to hire reliability engineers but don’t have a clear understanding of what they actually need, or what skills to focus on in their hiring process.

In this context, one of the topics I have been planning to write about is Failure Mode and Effects Analysis (FMEA), a widely used engineering tool in product and process risk management. Early in my career as a reliability engineer, I read a lot about FMEAs and grasped the basic idea behind them, but in practice my FMEA sessions never went the way they were described in books and academic papers. As with many engineering concepts, what’s on paper and what happens in reality don’t always align — and that’s what motivated me to write about it.

Let me be very clear here: if you are here to learn how to do an FMEA, this is probably not the right source for you. There are many good trainings and books out there on the subject, and personally, the best book I have read so far is Effective FMEAs by Carl S. Carlson. Carl did an amazing job of systematically laying out the entire process.

However, my main goal in this article is different. I want to talk about the practical challenges — the things that are rarely written anywhere — that I have experienced throughout my career. So, let’s jump in.

Ownership

The first thing I want to focus on is ownership: who should own FMEAs?

I believe in the saying, “If everyone owns it, then no one really owns it.”

If everyone owns it, then no one really owns it.

In my career, I have seen systems, reliability, or design teams take ownership of FMEAs. There are pros and cons to each approach, which I will talk about in a bit, but at least having someone responsible is a big step forward.

When reliability (under systems engineering) owns it, the process is usually systematic and step-by-step: functions are identified, associated failure modes and mechanisms are listed, risks are assessed, and so on. But it generally lacks ownership from the design teams who have the ultimate knowledge about the current design. Reliability engineers often do not have deep technical knowledge of the design, so they end up chasing design engineers for information. Meanwhile, design engineers, who already have a full plate of tasks, don’t prioritize FMEAs unless the benefits are clear to them. When those benefits are not communicated, the process turns into a nightmare for reliability engineers, who eventually end up working in isolation.

On the other hand, when design teams take full ownership without any reliability engineer’s involvement, the opposite problem emerges. A huge amount of time is spent cataloging individual component failure modes, including extremely unlikely ones, but the system perspective is lost. What begins as a system risk analysis exercise quickly turns into a time-consuming documentation effort with little connection to meaningful system design decisions.

A slightly better version is when design teams still own the process but are supported by reliability engineers. In this case, reliability engineers act as facilitators, helping teams structure risks, prioritize them, and burn them down in a meaningful way. Ownership remains with design, but the process gains the structure and discipline needed to produce real value.

In reality, there is no single right answer. As engineers like to say, “it depends” — and it really does. Considering how complex and interconnected today’s technological products and processes are, having a systematic way to identify risks, prioritize them against system goals, and manage them proactively is critical to getting real value out of FMEAs. In my view, systems teams (including reliability engineers) should own FMEAs early in the design cycle, when design decisions are still at the high, system level. Here the focus should be on system-level risks using a top-down approach, which I am going to explore in the next paragraph. As the design matures and details solidify, ownership should shift to design teams, while systems and reliability engineers step back into the role of facilitators to support the process.

Top-Down or Bottom-Up?

This is a sensitive topic for many reliability engineers. In particular, professionals from a defense industry background often advocate for the bottom-up approach and refer to MIL-STD-1629, which was later cancelled by the DoD.

The biggest issue I see with bottom-up is the risk of wasting time on risks that do not matter at the system level within the specific operational and environmental conditions. When individual component teams start working on FMEAs without a clear system view — without high-level functions, constraints, and interfaces — they end up listing every possible failure mode, even those that have little or no impact in the system context. For example, a bearing may have dozens of different failure modes, but whether those modes matter depends entirely on the system. Is the bearing used in a car engine, a kid’s scooter, or a rocket engine pump? Without context, you waste energy analyzing irrelevant details.

To illustrate: imagine a system that consists of 5 components, and each component has 2 functions. Each function has 2 failure modes, and let's say each failure mode has 3 causes. That alone multiplies into 60 risks that need to be identified, assessed, and managed. You can see how quickly the numbers grow. The problem is that many of those mechanisms or causes at the lower levels of the physical hierarchy may be irrelevant, or represent extremely low risks in the context of the actual system being built in that specific environment and use profile. When you follow a bottom-up approach, this kind of noise is unavoidable and can exhaust your resources long before you create any real value.

This is why I prefer the top-down approach. You begin with the big picture, define system-level risks, then work your way down, filtering out what is irrelevant and focusing on the few risks that truly matter — often called the “vital few.”

In many organizations I have worked at, bottom-up was the default simply because that was the way things had always been done. Changing that mindset was often an uphill battle. But once the benefits of a top-down approach were clearly communicated, it almost always turned into a success.

Timing

Another important aspect of FMEAs is timing: when should you start?

Think of two extremes. On one end, you wait until the design is frozen and run FMEAs just to document findings. On the other, you start when there is only an idea — during brainstorming and concept trades. Personally, I prefer the second.

The purpose of FMEAs is to identify and manage risks structurally, and the earlier this is embedded into the decision-making process, the better. I like doing functional FMEAs in the early stages, when little is known about the physical design, and then refining them as the design matures. The later you start, the more likely FMEAs become a pencil-whipping exercise that adds no value.

In practice, however, reliability engineers are often brought into programs late in the cycle. By then, FMEAs may already have been performed poorly, people are frustrated, and trust in the process is gone. That makes the reliability engineer’s job much harder, as they must first prove the value of FMEAs and often try to salvage existing ones. In some cases, I found it easier to start from scratch rather than trying to fix a broken process. If you hear skepticism about the usefulness of FMEAs, it almost always means the purpose of the process was not well understood, and the common mistakes I described earlier were made.

Where to Stop

Another aspect of FMEAs that I personally struggled with — and where I wasted an incredible amount of energy and resources early in my career — is the question we should all be asking: “How deep in the physical hierarchy should we go?”

To give you an idea, take a pump. Do we stop at the impeller and simply note “impeller breaks,” or do we go deeper and analyze specific crack mechanisms on the impeller surface? Or take a printed circuit board: should we stop at the board level, or continue breaking it down into every resistor, capacitor, and diode?

My rule of thumb is simple: stop at the point where you no longer have meaningful control. If you cannot make design changes at that level, if you lack the data or visibility to properly assess risk, or if the component is entirely sourced from an external supplier whose internal design you cannot influence, then drilling down further only produces paperwork. It adds complexity without making the system any more reliable.

The reason this matters is that going too deep drains resources and dilutes focus. I have seen teams spend weeks cataloging resistor-level failure modes in a purchased PCB. It looked impressive on paper, but in practice it contributed nothing to the reliability of the final product. What truly makes a difference in that situation is specifying clear performance requirements, testing effectively, and qualifying suppliers — not listing every possible failure of a resistor you don’t design or manufacture.

There is also the problem of complexity creep. Every function branches into modes, every mode into causes, and soon you are staring at a spreadsheet so large that no one can realistically use it. That is when FMEAs lose credibility and get dismissed as “just compliance paperwork.” By contrast, if you stop at the right level — the highest level where your team can still influence the outcome — you preserve clarity. The FMEA remains lean, credible, and actionable. Most importantly, it directs attention to risks you can actually manage, rather than drowning you in noise that you cannot.

In Summary

FMEA is just another tool from the Design for Reliability Process toolkit. We should not perform it just for the sake of tradition or compliance. Like any tool, its purpose is to provide information that helps us make better decisions and improve design.

At its best, FMEA is not about filling out sections or checking boxes. It is about the actions it drives, the insights it uncovers, and the design decisions it informs. That is where the real value lies.

Imagine you are tasked with designing a long-range electric vehicle. Just for the sake of simplicity in this analogy, let’s assume the vehicle has only 5 subsystems: energy storage, electric drive, thermal management, chassis & dynamics, and controls.

Your analysis tells you that you need to achieve 95% reliability on these vehicles over 5 years under predefined environmental and use conditions.

Now comes the tricky part: how are you going to assign resources? Will the energy storage system get the most attention because it is the heart of EVs? What about chassis & dynamics — is it more important than the electric drive? Or do you just split it equally and call it a day?

Let’s look at a few options.

One way is to assign the system-level reliability equally to the 5 subsystems. That gives each subsystem about 98.98% reliability.

Another way is to weight certain subsystems more heavily, for example:

• 99.5% (energy storage)
• 99.5% (electric drive)
• 99% (thermal management)
• 98.5% (chassis & dynamics)
• 98.5% (controls)

This still achieves the 95% system-level goal. Or you could choose yet another combination, such as:

• Energy storage – 99.9%
• Electric drive – 99.5%
• Thermal management – 99%
• Chassis & dynamics – 98.5%
• Controls – 98%

All three approaches technically work. They all get you to 95%.

So which one should you go with? As you probably guessed, the engineer’s favorite answer applies here too: “it depends.” Keep reading and I’ll explain why.

From Requirements to Allocation

In my last article, I talked about the Design for Reliability (DfR) process and its first phase, Define, where we set system-level reliability requirements. But setting a top-level number is only the beginning.

As the design matures and the system hierarchy starts to take shape, we need to break down that requirement and allocate it to subsystems, components, and eventually parts. In this part, what I mostly heard in my product development experience was that “we need to do the right allocation.” The truth is, there is no such thing as the “right allocation.” What you are really after is the optimum allocation — the one that fits your actual constraints, whether that’s technological maturity, cost, mass, schedule, or safety.

There is no such thing as the “right allocation.” What you are really after is the optimum allocation.

Before diving deeper, let’s pause for a quick refresher.

At the simplest level, we usually deal with 2 types of reliability configurations:

• Series: the system fails if one element fails.
• Parallel: the system works as long as at least one element works.

For each configuration, system-level reliability can be calculated using the formulas shown in Figure 1. Of course, real systems are rarely this simple. In practice, you’ll see dozens or even hundreds of series and parallel combinations stacked together.

That’s why before you attempt allocation, you need to map the system reliability configuration first — usually through Reliability Block Diagrams (RBDs). I may write a dedicated article about RBDs in the future, because they deserve more detail than I can give here.

Now let’s return to our vehicle design. Remember the three allocation scenarios we looked at earlier? All of them get you to a 95% reliable vehicle, but probably not all of them are feasible.

Here’s the catch:

• One allocation may require technology maturity that simply doesn’t exist
• Another might demand testing programs that are too costly or time-consuming
• A third might place too much risk on subsystems that directly impact customer safety or satisfaction

And this is the heart of reliability allocation: it’s not just math. It’s about trade-offs.

Why Allocation Matters

Think about how engineering teams are structured. In automotive, you’ll find powertrain, chassis & dynamics, and interiors. In aerospace, turbomachinery, avionics, propulsion, valves, and so on. Each team focuses on its area, but together they create the whole product.

If reliability is only defined at the system level and never broken down, each team is left guessing. Some will over-engineer, pouring in resources that don’t add value. Others will under-engineer, creating weak spots that compromise the whole. Testing and budgets will be misaligned.

But with allocation, those top-level requirements turn into concrete goals that each team can act on. Suddenly they know what they are responsible for, how to plan their resources, and which risks to prioritize.

I also want to mention here that these allocated numbers are not hard requirements. They are negotiable design criteria. You won’t get it right the first time; adjustments will need to be made as you run tests and gather more data. And this is actually the beauty of reliability allocation — it forces different functions to coordinate with each other. If powertrain cannot achieve its allocated reliability, the gap might be compensated by improvements in chassis & dynamics, for example, if that is more feasible.

That’s why allocation is so important — it connects the system-level reliability target to the everyday decisions engineers make, while also providing flexibility as new data emerges.

Sources of Input

Where do allocation numbers come from? There are a few common sources:

• Historical failure data of similar elements,
• Supplier test results,
• Engineering judgment about design maturity and environment.

These are useful, but they are not the whole story. They should complement the allocation process, not drive it. Because allocation is not about copying the past — it’s about balancing constraints in the present: cost, schedule, weight, safety, customer expectations, etc.

Allocation Approaches

There are many methods out there to do allocation, from simple to advanced. At a high level, they fall into 2 categories:

• Factor-based allocation
• Advanced (optimal) allocation

Factor-Based Allocation

Factor-based methods rely on influence factors like complexity, state of the art, criticality, and environment that may have an impact on reliability. These are turned into weights, which are then used to distribute the system-level requirement.

The general formula is:

where:

• R_sys: system requirement
• R_i(t): allocated reliability for element i
• w_i: weight factor

The methods mainly differ in how the weight factors are calculated. The most popular ones you’ll see in the literature include ARINC, AGREE, FOO, AWM, and MEOWA.

My goal here isn’t to teach every method — there are plenty of resources online for that — but to highlight the philosophy behind allocation.

Over my 13 years in reliability engineering, I’ve used many commercial software packages that perform allocations automatically. They’re powerful, but they also come with two big frustrations:

• They usually assume exponential distributions and simple series systems.
• Their licenses are expensive, which makes them impractical for smaller companies that won’t use them frequently.

That’s why I decided to build something simpler. I created an Excel macro tool that performs factor-based allocation using three practical methods: FOO, AWM, and MEOWA. It’s straightforward, doesn’t need specialized licenses, and works well for many real-world applications, including systems with parallel reliability configuration.

Advanced Allocation

Advanced allocation goes further. It uses mathematical programming techniques to optimize reliability against constraints like cost, weight, and volume.

It can be set up in two main ways:

• Maximize system reliability while staying within cost limits, or
• Minimize cost while achieving a required reliability level.

These methods can, for example, determine the optimum number of redundant elements or the most cost-effective way to assign reliability in a parallel-series system.

The challenge? They require detailed cost-versus-reliability data, which is rarely available early in design. Still, in critical industries like aerospace and defense, where weight and volume are tightly constrained, these methods can be extremely valuable.

In Summary

Reliability allocation is not about finding a single “right” answer. It’s about finding the best balance for your constraints. Sometimes a simple factor-based approach is all you need. Other times, advanced optimization pays off.

What matters most is that allocation translates a system-level requirement into real, actionable design targets. That’s where its power lies.

And if you’re a reliability engineer without access to expensive commercial tools, my Excel macro might be exactly what you need. It’s a practical, affordable way to apply proven allocation methods and bring structure to your reliability planning.