For the past couple weeks, I’ve outlined a few thoughts on the difficulties related to doing engineering hero work. Before we move on to identify how to responsibly do your job yet maintain some reasonable quality of life, there’s an important question that we should contemplate: why is there such a frequent need for engineering hero work in the first place? If we took a survey to answer that question, I’d be willing to bet money the most frequently selected choice would be that development projects are understaffed. And absolutely, I agree projects are understaffed. However, in my experience, that incrementally increases the amount of planned work for each team member. The big problem is the occasional spike of work that becomes a 15 hour work day that is the real backbreaker. That often is not due to planned work, but instead is a result of unplanned work. Where does the unplanned work come from? There’s three characteristics that contribute to unplanned work.

All new products have unresolved issues after design release.

When one thinks of engineering work, lots of different terms come to mind: experimentation, discovery, invention, innovation and exploration to mention a few. But regardless of what word you use to describe it, engineering a new product often involves the development of new systems, materials, components or any number of other new items. Any new item will have a number of issues that, if left unresolved, will cause product level issues. And despite analysis, testing, qualification or any other type of procedure, some amount of product issues will be unresolved beyond design release. From there, they proceed downstream in the product development process.

The remainder of the product development process catches many product issues, which come back to engineering as unplanned work.

What happens to those product issues after design release? Luckily (or hopefully) a good number of those product issues are caught during the sourcing, production and quality testing activities in the rest of the product development process. These product issues are then entered into the change process where they return to engineering for resolution. However, returning unresolved product issues aren’t part of the schedule. If aware of them, they are resolved prior to design release. So all of these product issues show up as unplanned work.

Engineering is a flexibly resourced organization and acts as a buffer in the development schedule.

The problem here is that most engineering staff already has a fully loaded schedule. As we mentioned before, with many development projects already understaffed, the amount of planned work has already incrementally increased. But the unplanned work associated with these product issues are actually highly prioritized because the product is so close to their launch or delivery dates. As a result, both the planned work and unplanned work must be completed. That’s how engineering suddenly becomes a flexibly resourced organization. It’s not that some work is outsourced, that part time engineers are hired or more engineers have flex-time. It’s just that the same engineers work longer hours until the planned work and unplanned work is complete. Simply put, that’s the nature of engineering.

All in all, there are a few takeaway points.

• Development projects are understaffed, but it’s the unplanned work that causes the 15 hour days for engineers.
• The unplanned work comes from a sequence of events as follows.
• • All new products have unresolved issues after design release.
  • The remainder of the product development process catches many product issues, which come back to engineering as unplanned work.
  • Engineering is a flexibly resourced organization and acts as a buffer in the development schedule.
    

In the next few posts in this series, we’ll talk about some principles to follow to address these core issues.

Take care. Talk soon. And thanks for reading.