Your First 90 Days as an Automation Engineer on Site

Nobody expects you to be good yet

They expect you to be safe, honest and useful. Competence is assumed to arrive later. Almost every early-career reputation problem in this industry comes from failing one of those three, not from lacking skill.

Week 1: learn the plant, not the program

Resist the urge to open the software. Spend the first week understanding what the plant makes and how.

• Walk the line end to end with somebody who knows it. Twice.
• Learn what the product is, what a good one looks like, and what a bad one costs.
• Find the isolators, the emergency stops, the assembly point, the first aider.
• Learn the shift pattern and who runs each shift.
• Get the drawings, and find out whether they are current. They usually are not.

An engineer who understands the process makes better decisions than one who only understands the controller. This is also how you stop being the person who takes a line down at the worst possible moment, because you now know when the worst possible moment is.

The safety part is not a formality

• Do not touch anything you have not been inducted on.
• Do not work on a machine without isolating and locking it, ever, and never on somebody else's lock.
• Permits are not paperwork. If you are asked for one you do not have, stop.
• If you do not know, say so. Nobody has ever been sacked for asking whether something is isolated.

The fastest way to lose a site's confidence permanently is to be seen taking a shortcut around isolation.

Carry a notebook

Not your phone. A notebook.

Write down: tag numbers, who does what, where things are kept, the names of the maintenance team, passwords you are given, what you were asked to do and by whom, and every question you could not answer.

Two reasons. First, you will be told forty things in week one and remember six. Second, being visibly the person who writes things down changes how people treat you within about a fortnight.

Weeks 2 to 6: be useful before you are competent

You will not be trusted with the main line yet. What you can do:

• Loop checking. Tedious, essential, and genuinely valuable. See I/O loop checking. Do it thoroughly and people notice.
• Documentation. As-builts, I/O schedules, marking up drawings that are wrong. Every plant is behind on this.
• Shadowing breakdowns. Ask to be called when something fails, even at inconvenient times. One breakdown watched attentively teaches more than a month of reading.
• Small, low-risk jobs. A new alarm message, a screen tidy, a report. Deliver them completely.

The four mistakes that damage reputations

1. Making an undocumented change. Someone will spend a day chasing a behaviour you introduced. Always take a backup before you change anything, write down what you changed, and tell somebody.

2. Leaving forces in. A forced output left in a running processor is dangerous and, on some sites, a sackable mistake. Check for forces before you leave. Every time.

3. Guessing in front of an operator. If you do not know, say you will find out. Operators have watched engineers guess before, and they will not tell you when you are wrong, they will just stop asking you.

4. Hiding a mistake. Everybody breaks something eventually. Reporting it immediately is a minor event. Being found out later is a career event. This one is worth more than all the technical advice on this page.

Weeks 7 to 13: earn a piece of ownership

By now you should be asking for something of your own: a machine, an area, a project. Small and complete is better than large and shared.

When you get it:
- Learn it properly. Read the whole program, not just the part you are changing.
- Find out what it does when it fails, not only when it works.
- Improve one thing and be able to say what improved.

That is what goes on your CV at the end of the year, and it is what you will be asked about at your next interview. See portfolio projects that get interviews.

Working with the people who are not engineers

• Operators know the machine better than you do. They run it every day. When one says "it always does that after a changeover", that is a diagnostic clue, not a complaint.
• Maintenance technicians can usually fix it faster than you can. Learn from them rather than competing.
• Production wants the line running. Understanding why they push back on downtime makes you easier to work with and better at scheduling work.

Engineers who treat operators and technicians as colleagues get told things. Engineers who do not, do not, and then wonder why faults are so hard to diagnose.

If you are on a customer site

Everything above, plus: you represent your employer, the customer is watching, and you should never criticise their plant, their previous supplier or their people. Report problems to your own manager, and be careful what you say in front of whom.

Also: tell them straight away when you find a design error. Quietly patching it and not documenting it means the next person inherits a machine nobody understands.

Where the first 90 days start earlier

Trainees on the Automation Engineer Program join live client projects as junior engineers, which means the first-day-on-site experience happens during training, with somebody beside you. That is deliberate: the gap between a course and a job is mostly this, and it is better crossed under supervision.

Related: The fault-finding interview question, Control panel wiring standards.