Understanding the Role Shift

Before discussing skills, it's important to be precise about what changes when engineering automation is deployed. The question isn't whether your engineers will be replaced — it's whether your engineers will be the ones building and owning the systems that replace manual tasks, or whether that capability will sit with an external vendor.

In teams that handle upskilling well, automation creates a new class of responsibility: engineers who define the rules and logic that the automated system executes. These engineers need to understand their product deeply enough to encode design decisions as explicit, unambiguous rules — which is actually a higher-order skill than executing those decisions manually.

Manual variant drawing requires engineering judgment applied ad hoc, case by case. Automation requires engineering judgment formalised explicitly — every decision documented as a rule. The second approach demands deeper understanding of the product, not shallower.

Tier 1: Foundational Skills for All Engineers

Every engineer on a team moving toward automation should develop baseline literacy in these areas — regardless of whether they'll be directly building automation tools:

  • Parametric thinking: Understanding how product geometry and specifications relate to input parameters. Engineers who think in terms of "if load = X, then beam size = Y" are already thinking parametrically — this skill needs to be made explicit and applied to the team's specific products.
  • Data structure awareness: Understanding how product data is organised in CAD files, BOMs, and ERP systems. Engineers don't need to be database administrators, but they should understand why a product that works in CAD fails to transfer cleanly to ERP, and what data structure choices prevent that problem.
  • Basic spreadsheet automation: Excel and Google Sheets with structured formulas, named ranges, and basic scripting. This is often the entry point for engineers who haven't written any code — and the skills transfer directly to parametric CAD work.
  • Workflow mapping: The ability to document an engineering process as a flowchart with explicit decision points, conditions, and outputs. This is a prerequisite for building any automation — you cannot automate a process you cannot describe unambiguously.

Tier 2: Automation-Specialist Skills

A subset of your team — typically 2-4 engineers in a 15-person department — should develop deeper automation skills:

  • Scripting in Python or VBA: Python is the higher-value investment for the long term (broader ecosystem, better tooling), but VBA has the advantage of working inside the tools engineers already use (Excel, AutoCAD). Either language enables engineers to automate repetitive tasks, process data, and interface with CAD automation APIs.
  • CAD-specific rule environments: Autodesk Inventor's iLogic, DriveWorks rules, or similar platform-specific rule tools. These have lower coding overhead than full API development and are often the most practical entry point for engineers who aren't professional developers.
  • Template and master model design: Building parametric CAD templates that drive correctly from input parameters, with proper constraints, driven dimensions, and configuration tables. This is the engineering content that automation systems execute — getting it right requires both CAD expertise and parametric thinking.
  • Testing and validation thinking: Automated systems need automated testing. Engineers who understand how to define test cases for their product rules — including edge cases and boundary conditions — produce automation that holds up in production.

Tier 3: Developer-Level Skills

One or two engineers with ambition and aptitude can develop near-developer-level skills that give your team genuine technical independence:

  • C# or .NET for CAD API development: The Autodesk CAD APIs (AutoCAD, Inventor, Revit) are primarily C#/.NET environments. An engineer who can write and debug C# add-ins can build and maintain production automation tools without external support.
  • REST API integration: Connecting CAD automation systems to web services, ERP APIs, and configurator front-ends. This is the plumbing that closes the digital thread — and it's increasingly accessible with modern API tooling.
  • Version control (Git): Engineering automation code needs to be versioned, branched, and reviewed like any other software. Engineers who understand Git can participate in proper development workflows and avoid the fragility of automation scripts maintained in shared folders.

Change Management Comes First

Technical training is the easy part. The harder work is addressing the human dynamics around automation in an engineering team.

Engineers who fear that automation threatens their role will — consciously or not — resist it. They'll identify edge cases that "prove" the automation can't work. They'll document requirements vaguely enough that the automated system fails. They'll maintain the manual process as a backup long after the automation is production-ready.

The antidote is direct, honest communication about what automation will and won't change. Specifically:

  • Be explicit that headcount decisions are not driven by automation deployment
  • Involve senior engineers in defining the automation rules — they become authors of the system, not subjects of it
  • Celebrate early wins publicly: the first batch of variants generated automatically, the first customer delivery accelerated by automation
  • Give engineers visibility into the time saved — when an engineer can see that the system handled 40 variants this week that they would have spent 120 hours on, the value is concrete

A 12-Month Training Roadmap

Upskilling works best as a gradual progression, not a sprint. A realistic 12-month roadmap:

  1. Months 1-2: Workflow mapping workshop — every engineer documents one of their regular processes as a decision flowchart. This builds parametric thinking habits and produces the raw material for automation design.
  2. Months 2-4: Spreadsheet automation training — structured Excel/Python for engineers who haven't scripted before. Online courses combined with a weekly internal project (automate one real task in your current workflow).
  3. Months 3-6: CAD rule environment training — iLogic, DriveWorks basic rules, or the relevant platform for your CAD stack. Focus on your actual products, not toy examples.
  4. Months 6-9: First automation project — a real, production deployment of an automated task, however small. A single drawing variant type automated end-to-end is more valuable as a learning vehicle than a comprehensive training course.
  5. Months 9-12: Review, expand, and identify automation specialists — which engineers showed the most aptitude and interest? Invest in deeper technical training for them; let others focus on being capable users and rule validators.

Where to Start

The most effective starting point is a skills audit: where does your team currently sit across the tiers above? Most engineering teams have more scripting capability than they realise — engineers who maintain complex Excel models are closer to Tier 2 than they think.

Identify one engineer who is both capable and enthusiastic about automation. Give them dedicated time (20% is realistic, 100% is ideal initially) to develop their skills and build the first real automation. Their work becomes the foundation that the rest of the team learns from — and their results make the business case for the broader programme.