1) Books written for management and self-help have very limited applicability to highly technical, information-driven work. I have a copy of Atomic Habits but I haven't cracked into it so unfortunately I cannot comment specifically on that book. I *can* say that many common office productivity volumes are exactly the wrong thing to apply to engineering design, where deep work and freedom from interruptions is crucial to productivity. There is a vast portion of the business self improvement books that are written for an audience of managers / executives who bounce from one fad self-improvement method to another, and a successful book reinforces all of their happy business instincts. Another internal task force. Another LinkedIn post about how wonderful this concept is and how it's propelling them to their next stage of thought leadership. </retch> Which is to say, I don't think highly of this genre of books as a whole. Read them, consider them, apply a little bit to your personal life where it makes sense. Knowing where to apply a new idea is 100x more impactful than applying things just to see if they work.
2) I agree with the statement about 50% productivity means little until it's clearly defined. Do you have engineers operating at 100% productivity for comparison? How do you define 100% productivity?
3) What is the accuracy of the teams output? What is the (real) cost of errors? Are the errors discovered within the same facility or do they hide until the components are manufactured elsewhere before they are discovered at assembly? I work in a department that generates one-off designs and all components are manufactured by subcontractors. We invest more time in checking our work because it's very costly to discover an error at assembly. Make sure your productivity considers accuracy appropriately.
4) Discuss productivity issues with the team. In my experience, engineering teams are pushed to perform design before they have adequate information in hand. Is Sales providing adequate detail of what is required? Are the "productive" engineers just making assumptions to keep moving forward (and what impact does that have when the assumptions are not accurate)? Are design changes impacting total engineering time? Are the designs being reviewed and stage-gated at the appropriate intervals? Are all of the designs getting the benefit of the collective experience within the team?
5) Re-use of design data is very valuable in these situations but only if you can find the right design to re-use. Do you have well-organized part master data, such that you can search the existing part masters and quickly collect the closest existing designs?
6) Automate. Automate what? I hear this all of the time - but it only take one or two additional variables to water down the value of automation. Talk to the team, get their input because odds are, they don't enjoy doing the tasks that really are suitable for automation already.
7) I agree that incentives usually don't work. It' hilarious and tragic when management thinks they can craft a system that incentivizes engineering to be 'better' and then management's myopic incentive makes things worse - and splits the engineering team between those who chase the incentives and let the consequences fall later and those who see a different big picture and won't let the incentives sway them.
8) What other departments does the engineering team support, and how much of their time is going to those tasks? At many technical companies, engineering is the catch-all starting point for all of the other departments to begin solving a problem - whether or not it requires engineering support. It could be that the most 'productive' engineers are also the most supportive to the company. It's not necessarily a bad thing, but it needs to be in the team time budget and considered for what it is.
9) How do you manage the multi-disciplined aspect of the design? Does it go through mechanical first, then software, and so on? Or are the design teams working concurrently? And how well is that working?
10) Talk to the most experienced engineers - there are very likely excellent design practices in the past that were abandoned at some point but could be brought back into current practice for quick wins.
11) How are new projects documented and brought into the engineering department? If the information is not presented in a consistent way, then it becomes a mess and much of the engineering time goes into investigating and constructing the actual project requirements. The team ahead of engineering needs to know exactly what they sold and engineering should not proceed until *engineering* agrees they understand what that is.
