When a company deploys Operon, an engineer comes with it. Not for a kickoff meeting and a training session, but for the deployment itself: on site with your estimators, engineers and document controllers, working on your drawings until the workflow runs in production. We call the role forward-deployed engineering.
We work this way because industrial documents never arrive in a standard form. Every company has its own legends, tag conventions, templates and habits, and the fastest way to fit software to them is to put someone who builds the software next to the people who do the work.
Why we deploy engineers
A platform that reads drawings meets a different set of drawings at every customer. A mechanical contractor bids off sets from dozens of engineering firms, each with its own symbol habits and schedule formats. An owner-operator's units carry decades of legends, the numbering schemes of previous owners, and vendor packages drawn to someone else's rules. The models read all of it. What changes from customer to customer is the configuration around the models, and the way their output enters the work.
Little of that can be learned from a requirements document. It surfaces when an estimator says a count is wrong because this engineer always shows the return grilles on two sheets, or when a process engineer explains that line numbers changed format after a revamp. A forward-deployed engineer is there for those moments, can change the configuration the same afternoon, and can tell a reading error from a product gap.
The configuration that fits a customer's documents is learned at the customer's desk, not in a kickoff deck.
Week by week, from first drawings to production
Every deployment starts with one workflow: take-off on one bid type, a register for one unit, revision review on one project. The timeline below is the shape we hold ourselves to.
| When | What happens | Your team's part |
|---|---|---|
| Before kickoff | Choose the workflow, agree access and hosting, collect a representative set | Name an owner, share drawings and templates, settle security questions |
| Week 1 | Your own drawings read and verified | Your engineers or estimators verify the first reading with us |
| Week 2 | Legends, tag conventions and templates configured, exports mapped | Check the configuration against how you actually work |
| Week 3 | The workflow runs on live work | Run a real bid, register or review on it, with us beside you |
| Week 4 | Correction reviews, savings measured against the baseline | Decide when it becomes the standard way of working |
| After the first month | Your team runs it | Your team runs it without us in the room |
Week one is about evidence. We read a representative set of your own documents, not a demo set: the sheets your estimators find hardest, the scans from the oldest unit, the set from the engineering firm everyone complains about. The forward-deployed engineer sits with the people who know those drawings and verifies the reading with them, low-confidence items first. By the end of the week, your team has seen its own drawings read and checked by its own people, with every item traced to the sheet and region it came from.
By week three, the work is live. A bid due this month, a register for a unit in an active revamp, the revision review on a project that is still issuing drawings. We move to live work early on purpose. A pilot on closed jobs proves the software can read. Live work proves the team will rely on it under a deadline.
After the first month, it's yours. That means the team uses the workflow on real work without the forward-deployed engineer in the room, the output feeds the systems they already use, and someone at your company owns the result.
What gets configured
Most of a forward-deployed engineer's second week goes into configuration. Four things matter most.
- Symbol legends. Your legend sheets, and those of the firms whose drawings you receive, are mapped onto our symbol library: an owner's valve conventions, a consulting engineer's air device notation, a vendor skid's instrument balloons. Where a legend departs from a standard such as ISA 5.1, the legend governs. We explain why in Reading a P&ID like an engineer.
- Tag conventions. The grammar of your tags: line number formats, equipment prefixes, instrument numbering, and the older format on units that predate a renumbering. With the rules in place, a string that cannot be a valid tag is flagged for review instead of passed through.
- Templates. Where the output goes: the line items and assemblies in your estimating workbook, the line list columns your document control expects, the register format a handover specification asks for. Exports map into the templates your team already uses.
- Review routing. Who verifies what, at which confidence level, and who signs off. Role-based access is set here too.
Every configuration decision is written down, so it survives staff changes on both sides.
Running the first jobs alongside your team
The first live jobs are where trust is earned or lost, so the forward-deployed engineer is in the room for them. In practice that means:
- sitting with the estimator or engineer through the first verified job, explaining what a confidence score means and where review time should go
- running your usual method and the verified output side by side on the first job or two, and explaining every difference rather than averaging it
- logging every correction and sorting it: a configuration fix to make today, a drawing quirk to note, or a product issue to send back
- reviewing the corrections with your team lead each week and showing what changed as a result
Decisions stay where they were. Estimators still choose labor units and what to carry. Engineers still sign. The software reads and the people verify, for the reasons in Why we verify every tag.
Then the forward-deployed engineer steps back. The aim is a team that runs the workflow on its own. An engineer still doing the take-offs long after go-live has not finished the deployment.
What comes back to the product
Forward-deployed engineers are also how the product learns what to become. We do not train AI models on customer content, so what comes back is not your drawings. It is what the deployment taught us about the product:
- Configuration every deployment ends up needing, which becomes a standard option instead of a custom setting.
- Work done beside the product, often in a spreadsheet next to it, which points to a missing feature.
- Export formats and integrations that keep coming up across customers.
- Kinds of documents and conventions the product handles poorly, described in general terms, which shape what we build next.
- Friction in review, such as a screen that takes too many steps or a threshold that sends too much, or too little, to a person.
Each deployment makes the next one shorter, for the next customer as much as for you.
What to have ready
A deployment moves at the speed of access and decisions. Before kickoff, have these in hand:
- A named owner. The estimating lead, engineering manager or document control lead who decides whether the output is good enough to use.
- A representative drawing set, difficult sheets included. A deployment that only sees clean sheets gets configured for clean sheets.
- Your legends and conventions. Tag and line numbering procedures, drawing standards, and the document control procedure if there is one.
- Your templates. The estimate workbook, the line list format, the register or handover format the output has to fill.
- A live job within three weeks. A bid, a unit or a project with drawings moving.
- Time from the people who will verify. A few hours a week from one or two experienced people in the first weeks matters more than anything else on this list.
- An IT and security contact from day one. Hosting in an isolated cloud tenant or on-premise, role-based access, encryption in transit and at rest, and the audit log. Settle these before kickoff, not in week four.
One workflow, your drawings, live
A forward-deployed engineer's job is to become unnecessary to your daily work, quickly. In the first week, your drawings are read and verified by your own people. By week three, a workflow runs on live work. By the end of the first month it is owned by your team. For how a deployment fits an acquisition, see The first 100 days. For what runs underneath, see the platform. And if this is the work you want to do, see careers.
