Starting as the new automation specialist in a factory can feel like being handed responsibility for a system nobody fully understands.
The plant may contain several PLC brands, undocumented program changes, obsolete drives, unreliable networks, and machines that only one retiring technician knows how to restart. Production may expect immediate results, while you are still trying to find the correct software backup.
Your first 90 days should not be about redesigning everything. The goal is to understand the plant, protect its critical knowledge, build trust, and solve a few carefully chosen problems without creating new ones.
Days 1–30: Learn Before You Change
During the first month, resist the urge to prove yourself through major program modifications.
A machine may contain strange logic for a reason. An interlock that appears unnecessary could protect equipment during a rare operating condition. A timer that looks excessive may compensate for a slow mechanical movement.
Before changing anything, learn how production actually works.
Start by mapping the plant:
- Which machines are most critical?
- Which lines create the most downtime?
- Which PLC, HMI, drive, robot, and SCADA platforms are used?
- Which machines have reliable drawings and backups?
- Which systems depend on external integrators?
- Which controllers are obsolete or unsupported?
- Which machines are repeatedly modified?
Build a simple automation inventory containing controller models, software versions, firmware, network addresses, backup locations, and support contacts.
Do not spend weeks creating a perfect spreadsheet. Capture enough information that another person could locate the correct software and connect to the machine during a breakdown.
Befriend the Operators First
Operators often know a machine’s behaviour better than anyone else.
They know which sensor becomes unreliable after cleaning, which alarm appears before a jam, and which product format causes the most problems. They may not use technical terminology, but their pattern recognition is valuable.
Ask questions such as:
What usually happens immediately before this machine stops?
Which alarm messages are misleading?
What problem do you report repeatedly but never see permanently fixed?
Do not dismiss explanations because they sound untechnical. “The machine sounds different before it stops” may point to a slipping belt, failing bearing, or overloaded motor.
Operators will also decide whether to tell you about early symptoms or wait until the machine completely fails. Treating them with respect makes future troubleshooting much easier.
Build Relationships With Maintenance Technicians
The electricians, mechanics, and shift technicians should be your closest technical allies.
They know where cables are actually routed, which drawings are inaccurate, which spare parts fit, and what modifications were made during previous breakdowns.
Ask to accompany them on faults even when the issue does not initially appear automation-related. This helps you understand the entire machine rather than seeing only PLC logic.
Avoid becoming the person who blames every problem on wiring. Maintenance technicians will quickly stop cooperating if your standard response is, “The program is correct, so it must be electrical.”
Likewise, do not allow every fault to be labelled a PLC problem simply because the cause is not immediately visible.
Work through the signal path together: physical condition, sensor, wiring, PLC input, program logic, output, actuator, and mechanical response.
Find the Unofficial Experts
Every plant has people whose real influence is not shown on the organisation chart.
It may be the night-shift electrician who knows the oldest line, the production supervisor who remembers every modification, or the engineer who maintains a private folder of correct backups.
Identify these people early.
Ask:
Who gets called when nobody else can solve this machine?
Then spend time with that person before their knowledge disappears through retirement, resignation, or transfer.
Do not make them feel that you have arrived to replace or expose them. Explain that you want to reduce the plant’s dependence on undocumented knowledge.
Days 31–60: Secure the Basics
During the second month, focus on reducing obvious operational risks.
Verify that critical PLC, HMI, robot, drive, and safety-controller backups exist. A file is not verified merely because it appears in a folder.
Where authorised, compare the stored project with the running controller. Record the software version and the date of verification.
Create a controlled structure such as:
Plant → Production Area → Machine → Controller Type → Verified Backups
Store software in approved company systems, not only on your laptop.
Also check:
- Are programming licences available?
- Are passwords stored securely?
- Are the required cables and adapters present?
- Can old software still run on a company computer?
- Are drive parameters backed up?
- Is there a recovery process after controller replacement?
A successful recovery test is more valuable than a folder containing hundreds of uncertain files.
Learn the Plant’s Failure Patterns
Review maintenance records, alarm histories, and breakdown reports.
Look for:
- Repeated sensor failures
- Communication interruptions
- Drive trips
- Machines that fail after power cuts
- Programs with frequent emergency modifications
- Faults that appear only on particular shifts
- Problems linked to product changeovers
- Components repeatedly replaced without root-cause analysis
Do not immediately attempt to solve every recurring fault. Rank them by production impact, safety risk, frequency, and difficulty.
Choose one or two problems that are visible, manageable, and supported by evidence.
A useful first improvement might be adding a clear diagnostic message, correcting a recurring sensor installation problem, or creating a verified recovery procedure.
Avoid beginning with a complete software rewrite. Large early projects create risk before you understand the plant’s standards and politics.
Establish Change Control
By the end of the second month, every meaningful software change should leave a record.
The record should include:
- Machine
- Date
- Reason for change
- Program revision
- Person making the change
- Testing completed
- Approval or request source
- Updated backup location
Never overwrite the only known working project.
Before downloading, confirm that you have the correct machine, correct controller, correct project, and a recovery plan. Similar machines may contain different mechanical or software revisions.
Treat emergency changes with the same discipline. Production pressure is not a reason to lose the previous working version.
Days 61–90: Improve Reliability and Independence
During the third month, begin making the plant easier to support.
Create practical diagnostic tools for maintenance technicians and operators. An HMI screen for a motor might display:
- Safety circuit healthy
- Drive ready
- Overload healthy
- Automatic mode active
- Upstream permission available
- Downstream equipment ready
- Start command present
- PLC output active
This prevents every “motor will not start” call from requiring a programmer.
Develop short troubleshooting guides for frequent failures. Keep them specific and usable during a breakdown.
A one-page guide explaining how to recover a machine after a power failure is usually more valuable than a long general PLC manual.
Meet the People Who Control Your Workload
By the end of 90 days, build working relationships with:
Production management: They determine which problems receive downtime and funding.
IT or OT support: You will need them for network access, managed switches, servers, backups, cybersecurity, and remote connections.
Purchasing and stores: They determine whether critical spares are ordered correctly and available when needed.
Safety personnel: Program changes can affect machine movement, guarding, alarms, and operating procedures.
External integrators and machine builders: Know who can support systems outside your experience before an emergency occurs.
Explain technical risks in operational terms. Management may not care that a CPU is obsolete, but it will care that replacement could require several days because no compatible spare or verified backup exists.
What Success Looks Like After 90 Days
After three months, you do not need to understand every line of every PLC program.
A successful first 90 days means:
- Critical systems have been identified.
- Important backups are verified.
- Software changes are recorded.
- Key operators and technicians trust you.
- Recurring failures are being ranked and investigated.
- External support contacts are known.
- At least one visible reliability problem has been improved.
- Management understands the largest automation risks.
The biggest mistake is trying to become indispensable by keeping knowledge to yourself.
Your long-term value comes from making the plant more diagnosable, recoverable, and maintainable—not from ensuring that every breakdown requires your personal intervention.
Listen first. Secure the basics. Solve problems methodically. Then improve the system one controlled change at a time.