Handing off a project to another engineer can be daunting. Aside from the personal attachment (the project is your baby), it can be difficult to articulate where the project has been and where it needs to go. My background is in design engineering for the retail fixture industry, so I have worked for companies that are project based, not product based.
During that time, I have had to hand over many of my projects to other engineers. To me, the big challenge with handing off a project to another engineer is not the amount of information you need to provide them, it’s how disorganized the information you already have most likely is. Depending on how far along you have taken the project, it may have been changed several times before the “new” engineer even begins to look at it.
Several meeting notes, emails, and other fragmented bits of information are already in your possession (in different formats), and it is important that you get all of that information transferred to the replacing engineer. For efficiency’s sake, you will need to organize this information in a way that makes it easy to understand.
When transferring a project, the first thing I do is organize the information about the project into an email and deliver it to the new engineer. The purpose of this initial “kickoff email” is to get the “new” engineer more familiar with the project before we sit down and discuss the finer details. I try to keep this initial email somewhat brief and focused on the facts, not what you inferred from design discussions up to that point.
This is a great time to send them the location of any of the engineering files that you currently have. They should all be on Workbench anyway, so that’s easy. Additionally, you should send everything to them at least 30-60 minutes before discussing the project in-person. You want to give them time to poke around the project before you meet up with them.
The kickoff email does two things. First, it provides the new engineer with a first look at the project before you meet up, allowing them to begin to process the project before you sit down. Second, the email will serve as a place to go back to look over after you meet, which helps them remember some of the details down the road. It’s not exactly a single source of truth, but it’s close. When you sit down to discuss the project, hopefully the new engineer will have read the email, processed it, and are coming in with their questions ready.
During the meeting
During the meeting, try to focus your discussion on the design intent of the project, not the design itself. If you’re truly handing this project over to another engineer, the intent is what they really need. If you try to tell them how to design the project, it will hobble them. Empower them instead. Explain how you got where you are, and let the replacing engineer ask questions about the design. The more information you can provide to the engineer about the goals of the project, without telling him or her how it needs to be made, the better he or she can do their job.
After the meeting
After the meeting, email an actionable summary to the engineer afterward. List key points that were discussed during the meeting, as well as what action steps need to be taken to move forward. This may sound like overkill, but it is important because it helps keep everyone on the same page after the meeting. In-person discussions are non-linear in nature, (which is why they are sometimes better than emailing), but it is best to organize the thoughts into an email for future reference.
Why all the emails? Two reasons. First, organizing this information into a neat and clean closing email will allow them to focus more on the design, and less on remembering details. Second, this closing email can be used to build a task list from.
Think of yourself as a wrangler
When you’re handing off a project to someone else, think of yourself as a wrangler. Your purpose at that moment is to wrangle up the fragmented bits of information, parse through them, package it all up and hand it off to the new engineer in the most organized way possible. If you hand the project off correctly, you won’t have to answer as many questions down the road. That will save both you and your fellow engineer a lot of time, and reduce the interruptions you have throughout the day.