The Product Support Trap for Development Engineers
In all the companies I have worked, when the product development is finished it gets passed on to manufacturing and product support but the original developer retains ownership of the design. It's important that the product support department gets full training on how the product works, how to use it, how to diagnose problems in the field and on the bench, and what happens under misuse and failure conditions.
But I have never seen a product support department really own the design to the extent that they could diagnose down to component level in the hardware or line of code in the software, which means that the last line of technical support comes back to the R & D engineer. Too often, that last line is perilously close to the first line, such as when the support team are understaffed or a particularly difficult field problem arises. On each occasion, the support team need to drag the R & D engineer off his assigned project with very little notice, often within the hour of the problem arising. If the support staff are not involved in the solution, even if no design change is needed, they will not learn what the solution really was, so they will be unable to solve it the next time. Which leads to the R & D engineer being involved more often.
A long time ago, I was told that there are two common solutions which are used.
One is to have sufficiently capable support staff that they can handle any problem that comes up, even if that requires questioning or changing the design. They have to really feel their ownership of the design at the point; R & D no longer "own" the design, and in any case it should be owned by the company. The support staff have the authority, knowledge and skills to make whatever changes they see fit as long as the design continues to meet the requirements.
As more generations of products are designed, the support team grows to add these to its portfolio. The R & D team continues to work on and have ownership of one generation of products at a time. Of course they have knowledge of the history of development and can reuse features from previous products but they are free to fully spend their time on inventing the best possible next generation of products. The R & D team only needs to expand if they need more bandwidth (more products in this generation) or different technical skills than the current staff can handle.
The second solution is that there are two teams, let say A and B, which are both capable of, and responsible for R & D work and product support. Team A develops a generation of products over say 6 months, then it goes into production and Team A go into support mode for say 6 months. During this period, they are fully committed to support and do not start any new product developments. Once the product has undergone its field trials and most the issues have been ironed out, that work tails off and the team can return to R & D work. While Team A are in support mode, Team B are in R & D mode, so there is always a set of engineers working on developing new products at any one time. Team B also alternate between R & D and support with the same timeframe but out of phase.
Each team has long term responsibility for the products they develop as the final line of support, but after the end of the support mode, most support can be handled by first line technical staff. The advantage of this method of working is that R & D get to see the field problems with their designs first hand, and can put those improvements into the next generation without them being filtered out by a support department.
If neither method is used, nor some other means of taking ultimate ownership off the original R & D engineer, a build up occurs. The longer that the R & D engineer stays with the company, the more products they have to support, so the less time they get for new product development. Eventually, the company is paying for a very expensive support engineer and takes a bigger and bigger risk - that if that one engineer leaves, all those products can no longer be supported. This is much worse risk than just not having that engineer to develop new products, plus their knowledge base, and is a risk no company should be taking.