7 Things Remember When You’re the Boss

I aspire one day to lead a team or teams of engineers. I hope that when that happens I remember the list below. Things that,as a lowly engineer, I now notice. Add your suggestions to the comment section!

1) Respect your engineer’s time.

Don’t pull engineers into long meetings with no resulting actions. Talking is great, but as an engineer its the ‘doing’ that is my job. Every minute I spend in a meeting is a minute longer I have to spend in the  lab/fab/plant  that night to complete my tasks.


2) Don’t ask for special favors. 

I often get asked for ‘just one or two samples’ for some random tangent experiment that a director on my project wants to preform. These requests are invariably made to me alone in a hallway rather than the bi weekly meetings I hold specifically to establish priorities and discuss results for my process. If there is a critical experiment, I’m happy to work on it, but often these requests don’t make sense to perform at the time.

I have a plan. My system is booked for the next several months with that plan. Asking me to accommodate special requests is disrespectful to all of the work I have put into that plan. And often the results of these experiments aren’t even shared. As a manager or managing direction I think it is important to keep this in mind, and when critical experiments come up , make sure to ask them in the proper forum and frame the request with the understanding that this will likely disrupt plans the engineer has made.

3) When you ask for special favors , explain the question , not the DOE.

The best person to design and experiment is the person who knows the process best. This is the engineer. Period. I don’t care if you were hot shit when you were on the ground 10 years ago.

If, as a manager, you have a suggestion for a DOE phrase it as ” It would be interesting/beneficial to show customers the relationship between defects and pressure, could you get some data on that?” NOT ” Run five samples between 12 Torr and 50 Torr and measure defects”.

The experiment will be done better because your engineer knows his or her process better than you. This also shows that you have some trust in your engineer (and is a good way to see if that trust is justified).

4) Be present but don’t micromanage. 

In my opinion if you are asking for daily email updates from your team it means that you’re not present enough. I think ( and this might change as I have a greater understanding of management) that you should have a basic understanding of what your direct reports are doing on a day-to-day basis. This doesn’t mean taking their bathroom breaks, but it does mean that if they tell you ” Aww shit the pump broke, no process today” you have an idea of how that will impact the overall process plan.

I’ve seen a lot of managers, especially mid-level ones get caught up in meeting after meeting with higher-ups. They then aren’t available to their reports and consequently when the managers boss asks them what is happening that day they have to scurry to ask their engineers. Set some time aside each day when you are at your desk and available to your engineers.

5) Not everything is an escalation. 

Just because your engineers talk to you about some weird problem they are having in lab or with a design, it doesn’t mean they need help. Sometimes people just need to vent , and sometimes people just want to bounce ideas off of you. This is not an invitation to tell them what they should be doing or take over their project. Rather its an indication that they think you are competent enough to offer thoughts and suggestions.

And we engineers are nerds – sometimes something cool happens and we just want to tell other people how cool it is!

6) Give your people all the shit you want in private but defend the hell out of them in public. 

I’m going to tell you a story. One day a high level manager in my company complained because he saw several of the hardware technicians outside taking an extended smoke break. He then went to the tech’s manager, I man I will call ‘Bob’, to complain that they weren’t doing their job.

Bob absolutely tore the shit out of the complainer. Saying essentially that his guys worked hard and deserved their breaks and that its not like the process engineers were any better ( his exact words were something like” Do I ask how often the process engineers check facebook in the lab ?!”). Now Im sure Bob talked to his guys and made sure they were getting their work done. And I know for a fact that he asks for a lot from his team. But ‘publicly’ he defends his guys. Which means his techs don’t need to worry that their boss is going to throw them under the bus when things get hard.

Now a similar situation happened with a junior engineer on my team. The junior engineer made a mistake that led to a lot of lost time. But this mistake had been approved by a large group of people , everyone (including myself) had missed it. All of us were at fault and the junior engineer was the one who had realized the mistake and made it public. I sat in a meeting while a director essentially blamed the junior engineer for all of the issues. The junior engineers manager, lets call him “Tim” sat there and said nothing. It was bad.

Tim’s behavior essentially encourages his people to hide mistakes and bad outcomes because they now know that Tim will throw them under the bus as soon as they get bad results. Bad results and mistakes are part of the game. As a manager its your job to step up and explain this to higher-ups. You can give your people lots of shit later in private but in that meeting where everyone is coming down on your engineer for getting a bad outcome. That is your chance to step up and show that you are not a fair weather friend, taking credit for all of the successes but distancing yourself from the failures that are essential to that success.

7) When your engineers stop pushing back. You’ve lost them. 

Engineering is a creative profession. Most (good) engineers don’t do their jobs for the money. We do it because we get a thrill out of working out complex problems. When you take away all of the decision making and ownership and turn your engineers into yes-men who do only what you say, you have lost them.

Beware of the overly conciliatory engineer , she’s probably looking for another job.