What Do You Do When Your Engineers Are Failing?

Jeroen and I had worked with Tim, the engineer we had assigned to develop the DAC, before, and he was an excellent engineer. Yet, things were going really poorly.

Tim was behind schedule, and the interim design review he had was a disaster. There were over one hundred action items (you can think of these as bugs) for him to complete.

I didn’t have any confidence Tim would get the design right, and neither did Jeroen.

 

You may need to put new people on the design.

 

“I think I want to put Sid on the DAC,” Jeroen said. “He’s very methodical.”

“Yeah, Sid’s a good choice,” I said. “Except I don’t think he’s designed a DAC before.”

“I know,” Jeroen said. “Sid’s good at complexity. And this design is complex.”

“Agreed,” I said. “Do it.”

And, with that, Jeroen made the change, putting Sid in charge of the DAC.

 

You need to dig into the details when a design is failing.

 

Sid, as was his norm, started digging in. I went by his cubical the day he was given responsibility for the DAC, and I asked him how things were going.

“Oh man,” Sid said, “It’s a mess. The existing design (of Tim’s) is completely broken. I’m likely going to have to start almost from scratch.”

“Do you think there’s anything you can salvage?”

“I don’t know, Brett. Tim’s a smart guy, so I’m hopeful. I’ll let you and Jeroen know in the next day or two.”

It was sobering to hear, but it is necessary to hear the truth from your engineers. It’s also necessary to have really good engineers too.

It’s really difficult to fix a design if you don’t have really strong talent managing the design. In our case, that was Sid.

 

Then, you need to have daily reviews of progress.

 

One of the things I really loved about working with Sid was he was okay with being challenged. It’s a trait I’ve seen in almost every really good engineer I’ve ever worked with.

Even though we believed in Sid, the DAC design was too important to treat it as a normal design. The financial leverage we were going to get from the design was huge.

Plus, it was going to be the fourth chipset we had introduced. Our investors would be all over us if we didn’t continue executing at this early stage in the life of our company.

Jeroen, to his credit, did exactly the right thing. He had a meeting with Sid every day to review the progress.

Jeroen and Sid broke the design down into a daily schedule of progress. We literally knew each day what was supposed to be completed.

You have complete transparency when you break an engineering schedule into daily chunks because there’s nowhere to hide. You’re either on schedule, ahead of schedule or behind schedule each and every day.

A daily schedule forces rigor. A daily schedule forces your engineers, if you’re doing things right, to ask for help.

 

Have lots of peer reviews of your designs too.

 

Sid got his arms around the complex design within a week. By the end of the second week with Sid at the helm, he had his first design review.

Our design reviews were not for faint of heart. Sid’s peers, all of whom were excellent design engineers in their own right, would judge his work.

The result of the first review was a detailed set of action items that examined weaknesses in the design that Sid needed to address. Sid added these to his plan and he continued improving the design each step of the way.

Six months later, on schedule, all forty products of the DAC were announced. We had averted disaster.

The issue with Tim not being up to task had to do with his wife being pregnant with their first child. She was having difficulties with the pregnancy, so Tim was distracted. He asked Jeroen for a leave of absence, which we obviously gave him.

His wife gave birth to a healthy baby boy and Tim returned to work.

 

Do You Want To Grow Your Business?  Maybe I Can Help.  Click Here.