Engineering Managers
Plan, organise, direct, control and coordinate the engineering and technical operations of organisations. Oversee teams of engineers, related professionals, and support personnel to deliver engineering projects in a range of industries and engineering disciplines.
A tight project at Southern Cross
You are an engineering manager leading a team of eight on the design of a new water pump, with a customer demonstration in three weeks. It is Monday and the team's schedule is already tight. A key engineer is away unwell, a supplier has changed a part and a manager from sales wants an early look at the design.
Choose what you would do. Then see what happens. There are often good reasons for each choice.
The supplier has swapped a bearing for a cheaper one. It is supposed to be equivalent, but the data sheet is a bit vague. I would like to test it properly, which takes a week we do not have. Or we can trust the supplier and carry on.
Ask Ximena for a short test of the likely failure while the supplier sends better data
A two-day test finds the problem and the supplier supplies better data. You keep the date and protect the design. Targeting the real risk is what experienced engineers do.
Trust the supplier, because the data sheet says it is equivalent and the schedule is already tight
The part is not quite equivalent at high load. The problem surfaces during the demonstration, in front of the customer. A vague data sheet was a warning you chose not to follow.
Test it fully, even if it costs the demonstration date and means telling the customer
The part is verified, but you miss a chance to find a faster way, and the customer is told the demonstration will be late. A smarter plan could have protected both.
A customer saw a sketch and loved it. I told them we could add a feature they asked for. It should be easy, right? I mentioned it would be in the demonstration. I hope that is all right.
Tell Reggie he should not have promised anything, and that sales must stay out of the engineering plan from now on
You are right about the process, but Reggie feels attacked and the two teams drift further apart. The customer's interest is still unanswered.
Explain what the feature involves, offer a concept version for later and agree how sales checks first
Reggie understands the cost and the customer still hears a positive plan. A simple agreement stops the next surprise, and the two teams are working together rather than against each other.
Agree to add the feature, as the customer is excited and it would impress them in the demonstration
The feature is rushed and disrupts the rest of the design. The demonstration is full of small glitches, and the main product looks less polished than it should.
I have two ways to build this casing. One is clever and lighter but harder to repair. The other is conventional and easy to service. I prefer the clever one, but I know you are the one who decides. Which do you want?
Choose the conventional design, because it is simpler and you trust it
The decision is safe, but you never asked about the customers who would use it. Dev feels his idea was dismissed without a hearing.
Tell Dev to pick whichever he prefers, since he knows the design best
He picks the clever design. Customers who work in remote areas find it hard to repair, and complaints follow. A manager who hands over the decision also hands over the responsibility without support.
Ask who will repair it, where and how often, and weigh the answers with Dev before deciding
Together you see that remote customers need the easier design, and Dev adapts his clever idea to be partly serviceable. He feels heard, and the decision rests on evidence.
How it went
By Friday the bearing is tested, the sales promise is reshaped and the casing decision is made. Engineering managers spend less time designing and more time helping others decide well, with an eye on safety, time and cost. Would you rather build things yourself or help a team build them better?
This is a simplified, fictional situation to help you explore. It is not professional instruction or a test of your ability.
Case study: The pump that passed every test
A fictional case set in the engineering department of a fictional company that designs and builds pumps for mines and farms.
The situation
Engineering manager Gabriela Ruiz led a team at Southern Cross Pumps, who had designed a new, lighter pump for farm use. It had passed every bench test. The sales team had a major order lined up and the launch date was fixed. A junior engineer, Tobias, quietly mentioned that the bench tests used clean water, while real farm water carries grit. He had not run a test with it. He felt awkward raising it so late and said he might be worrying over nothing.
What they did
Gabriela thanked him sincerely and asked him to design a simple grit test on the spot. She told the sales director that the launch might move, and explained why in one short paragraph without jargon. She set aside an engineer from another project to help Tobias and cleared the schedule so that the test could run for the full period, not a shortened one.
How it turned out
The pump wore faster than expected in gritty water. The team changed one part, retested and passed. The launch slipped by a few weeks and the sales director grumbled. Gabriela added a gritty-water test to the standard checklist and made sure Tobias presented the finding at the next team meeting.
What would you do?
- Why did it matter that Tobias felt able to raise the problem so late?
- How would you decide whether a late concern is worth delaying a launch?
- What do you think an engineering manager does that an engineer does not?
