Workflow Automation Engineer

About the Company

In regulated processes, cross-functional work runs across siloed teams and fragmented systems. The hidden cost of holding that work together is what we call Coordination Tax. the company makes it visible, measurable, and reducible, so that decisions, evidence, and completion stay connected across every team involved.
Some of the people who run on the company:
A carmaker bringing an iconic American off-road name back as an electric truck. A manufacturer of the radio-frequency coils that go inside MRI scanners. A chemicals company making the catalysts oil refineries and petrochemical plants depend on. An employee-owned engineering firm, over a century old, building the telescoping masts that go up on fire trucks and military vehicles. A consumer health company whose products sit in millions of kitchen cupboards.
Electric trucks, MRI hardware, refinery catalysts, masts for emergency vehicles, supplements people swallow. Every one of them has to prove what they did and why, to somebody who can shut them down.
That proving is what they use us for. The platform is configuration-heavy and no-code by design, which means the interesting work is not writing a system from scratch. It is modelling somebody's actual process accurately enough that they will use it on a Tuesday when nobody is watching.
Most software in this space is a form-filling exercise bolted onto a department. Our argument is that the cost lives between the departments, in the coordination nobody owns. That is a harder thing to build and a much better thing to be right about.

What you will own

• The build, on your assigned modules. Configuring workflows, forms, fields and process logic in the platform so they match how a customer actually works, not how the org chart says they work.
• Automations, and the specification before the automation. You write the spec first. This is not bureaucracy, it is the only way anyone can check the thing later.
• Data modelling, migration and document template creation for your accounts.
• Artificial-intelligence-assisted document generation, and then verifying it. We generate a lot with tooling. Shipping generated output without reading it is the one thing that will get you in trouble here.
• Test execution against requirements, with results recorded.
• Your part of the customer conversation. You will be on account calls. You are not expected to run them, you are expected to speak on them and to be able to answer for what you built.
• Enough account context to cover. When the lead is unavailable, you know what is going on well enough to hold the line for a day.
• Patterns back into the library. When you build something reusable, it becomes reusable for everyone rather than staying in your head.

What this role will not do

• Own the customer relationship, the delivery plan or the commitment to the customer. That is the Implementation Lead.
• Own or sign off a delivery gate. Also the Implementation Lead, and above them the Director.
• Author the user requirements or the test scripts. You contribute to both and may draft either. The Lead is the author and carries the accountability.
• Own integrations, identity, defects or platform capability. That is Platform and Engineering.
• Own the automation roadmap. That belongs to the person running the automation function.

Career trajectory

Worth being straight with you, because the honest version is unusual and you should decide against it if it does not suit.
The growth here runs toward owning solutions and customers, not toward deeper code. If what you want is to be a stronger engineer every year, say so now, because this is the wrong seat for it and you would know that within a year. What compounds here is judgement: about processes, about what a customer actually needs, about which problems are worth automating and which are not.

Three paths open from here, and all three are real.

Implementation Lead: You start owning the solution rather than the build: on calls, deciding the approach, managing what a customer can and cannot expect, and directing the build rather than doing all of it. This is the most common path and the ladder is genuinely short.

Integrations and platform depth: If the technical side is what keeps pulling at you, integrations sit at the boundary between our platform and a customer's systems, and that is closer to engineering.

Specialist: Some people turn out to be the person you send at the genuinely hard problem, the account nobody else can untangle. That is a destination in its own right here, not a consolation.
We would rather you pick one deliberately in year two than drift.

What we are looking for

Must-haves

• You can write and debug scripts competently. Structured query language and data handling to a working standard. You do not need to be a systems engineer.
• You can reason from a problem to a method, on a problem you have not seen before. This is the whole gate and it is the one thing we cannot teach. Not that you know the answer, but that you can work out an approach and explain why.
• You check generated output instead of trusting it. We use artificial intelligence heavily. The failure mode we care about is confident output nobody read.
• You want to move away from full-time coding toward work closer to customers and the product, and you can say why in a way that holds up.
• You are willing to learn an entirely new industry from zero. Almost nobody arrives knowing how a medical device company handles a corrective action. That is fine. Indifference to learning it is not.
• You take feedback. You will be corrected often in the first six months, sometimes bluntly.
• You are willing to be on customer calls and to speak on them. Accent is irrelevant. Being audible and useful is not.

A computer science degree is not required. Neither is domain knowledge or previous customer-facing experience.

Strongly preferred

• Exposure to a regulated industry: medical devices, pharmaceuticals, life sciences, aerospace, automotive, food.
• Hands-on experience with a no-code or low-code platform.
• Any prior customer-facing exposure, however small.

Permanent hard nos

• You want a deep backend engineering career. You would be bored, and we have made this mistake before.
• Test or quality-assurance automation only. Different discipline. If your automation experience is writing test suites or robotic process automation scripts, the overlap is smaller than the shared word suggests.
• You can only follow a pattern. If a problem does not resemble one you have seen, you stall.
• You are not open to feedback. The specific version we screen hardest for is the candidate who already knows everything. It closes the door on learning and it is the failure mode that has cost us most.
• You need the same thing explained repeatedly before it lands.
• You do not want to talk to customers.

What excellent looks like in 12 months

• You are trusted across more than one Implementation Lead, and they ask for you by name.
• Your builds pass review without material rework.
• You have written automation specifications that someone else could pick up and understand.
• You speak substantively on customer calls, unprompted.
• You have caught something wrong in an existing configuration that nobody else had noticed.
• A pattern you built is in general use across accounts.
• You have picked your next direction deliberately: lead, integrations or specialist.

How we work

You are on customer calls early. Two people on every account call, and both are expected to talk. There is no long apprenticeship where you sit silent.
Written first. The specification comes before the automation. Decisions live in documents. If it is not written down, it did not happen.
Artificial intelligence is a tool you are expected to use well, which mostly means checking it. We would rather you generate a draft and correct it than write everything by hand, and we would much rather that than ship something you did not read.
Direct feedback, both ways. You will be told when something is not good enough. We expect you to say so too, including to people more senior than you, including about the platform.
Reviewed, not unsupervised. Your automation work is reviewed. The Lead carries accountability for the build being correct. That is deliberate: it lets us hire for reasoning rather than for scar tissue.

Why this role is interesting

The usual version of this job is configuration work at a software vendor: a ticket arrives, you build what it says, you never meet the person who will use it. The ceiling is speed.
Here you are in the room. You will hear a quality manager explain why the current process takes thirty days, and then you will build the thing that takes it to eight. You will be on the call when they see it. That loop, from hearing a problem to shipping the answer to watching it land, is short here in a way it is not at larger companies.
The second reason is leverage. Part of this work is building the tooling that makes the rest of it faster, which is a far better problem than doing the same thing quicker by hand.
The third is the domain. Manufacturing under regulation is not fashionable and it is genuinely hard, which is exactly what makes it good to build for. The workflows are complicated because the consequences are real: an audit trail that does not hold up, a change nobody can explain eight months later, a product recall that traces back to a decision made in an email. Almost nobody builds well for this, and the incumbents have had thirty years to try. Software where being wrong matters is more interesting to build, and a great deal harder to copy.

Location and work model

Bangalore, hybrid, three days a week in office. Our customers are in United States time zones, so the day runs later than a standard Indian shift, roughly 2pm to 11pm and shifting an hour with daylight saving. Not a night shift.