A Computational Design Automation Specialist Belongs Inside the Design Team

The Stair Core Changed on Tuesday, and That Is the Job

The stair core moved four hundred millimetres on Tuesday. The tread count changed with it, so somebody spent Wednesday updating tags and schedules across forty sheets, and on Thursday structure came back with a different floor-to-floor and the whole exercise ran again. Nothing about that week required design judgment after the first hour. That is the work practices are now hiring a person to remove, and the word Automation is starting to appear in the title itself ¹.

Three traits separate a real computational design automation specialist from someone who has finished a Grasshopper tutorial, and each has a tell you can check in under an hour.

The first is that they ship tools other people use. Ask who else ran the script, and listen for a colleague's name. A real answer arrives with a support burden attached: the version that broke when the office upgraded, the two hours spent writing an error message a project architect could act on, the person who kept using it while its author was on leave. A performed answer opens a definition on a screen and shows a rendered image. Both look impressive; only one survives contact with a deadline.

The second is that they know the building and not only the graph. Ask what they refused to automate. Strong candidates have a case ready, usually something like unit mix, egress width or a facade module where the rule was easy to write and wrong to apply, and they can say who made the call instead. Someone who cannot name a boundary will eventually script one that quietly encodes a decision nobody made on purpose.

The third is that they read rather than click. Ask about a script that damaged a model, because everyone who has done this has one. The answer worth hearing describes what they read afterwards, usually the API documentation or a transaction log, and the guardrail they added. Purge the model, log the change, run in a detached copy first, refuse to run on a workshared central without a confirmation. Those habits come from having lost something.

Running through all three is one tell: a real candidate keeps asking who maintains it. Describe the tool you want and they will circle back to what happens when the software updates and they are on another project. That instinct is what separates this seat from a consultant engagement, and it is also the line between this role and a design technology director, who owns the standards and the platform rather than the scripts inside one job.

Which Backgrounds Actually Produce This Person?

The most reliable feeder is an architect on your own staff who started scripting to survive a project. They already know what a construction document has to say, which is the expensive half of the knowledge, and the scripting half can be taught. Look for the person whose name is on the office's shared Dynamo folder, or the one who quietly stopped complaining about sheet setup two years ago because they stopped doing it by hand.

Fabrication and facade engineering produce the second group, and they are often stronger on geometry than anyone hired from a design studio. Somebody who has driven a CNC router or resolved a panel schedule for a curved wall has been forced into tolerance thinking, and tolerance thinking is what stops a parametric model from producing beautiful geometry nobody can build. They also tend to have written code against a machine that punished ambiguity, which is good training for an API.

The unexpected feeders are worth naming because practices skip them. Structural and MEP engineers who automated their own coordination work transfer well and bring the discipline the design side usually lacks. Game and visual effects technical artists have spent careers writing node graphs and tools for artists who do not code, which is precisely the internal-tools job. And a survey or geospatial background produces people who are comfortable with messy point data and coordinate systems, which is most of what a site model is.

Two profiles read well on paper and often disappoint. Pure software engineers with no building knowledge write excellent code against the wrong requirement, and they can be hired successfully only next to an architect who owns the brief. And the competition-portfolio candidate, whose work is a wall of generative form studies, may never have handed a tool to a colleague. Ask that person a scheduling question and watch what happens.

A note on scale. The pool is not tiny but it is thin at the senior end, the openings that do exist sit mostly inside large multidisciplinary practices ¹ rather than anywhere a smaller firm can recruit from in volume. If you are competing for the same twenty people every firm in your city wants, promoting from inside is usually faster than winning a bidding war, and it costs less than the search.

Ask How They Taught Themselves, Including With AI

Ask directly how they got good, and let the answer run. The strongest people in this role learned by shipping something small to a colleague, watching it break in a way they had not imagined, and changing how they work because of it. They can name the tool, the colleague and the failure. Coursework answers are not disqualifying, but they rarely predict who will still be maintaining a script in month nine.

AI assistance is now part of that story, and it is worth asking about plainly rather than treating it as a confession. A model will write a plausible Revit API call that does not exist, or a Grasshopper approach that works on the sample geometry and collapses on the real one. What you want to hear is what they do about that. Good answers describe running the generated code on a detached copy, checking a method against the actual documentation rather than the chat window, and keeping a small set of test models that a change has to survive. One candidate describing the moment a confident wrong answer nearly went into a live model, and the check they have run ever since, tells you more than any list of tools.

Press on the habit of verifying against something outside the conversation. A model asserts that a parameter is writable through the API; the specialist opens the documentation or tries it in a sandbox. A model proposes a panelization strategy; the specialist checks it against a fabrication constraint the model has never heard of. This is easy to describe and hard to perform, which is why it belongs in a work sample rather than an interview question.

One warning about format. A portfolio review rewards the visual half of this discipline, and the visual half is not the job. Two hours with a messy real model, a stated goal and permission to ask questions will separate candidates that a slide deck cannot. Watch what they do in the first ten minutes: the real ones audit the file before they write anything, because they have been burned by a model whose worksets and shared parameters were not what the brief claimed.

Find Them in the Script Threads, and Close Them on Authority

Look where scripts get shared and debugged rather than where finished projects get published. The forums attached to Rhino and Grasshopper, the Dynamo community, GitHub repositories for open packages that Revit and Rhino users depend on, and the AEC technology meetups that run in most large cities are all populated by people doing this work under other job titles. Somebody who has answered thirty questions about a package they maintain has demonstrated more than a portfolio page can.

Adjacent titles to approach by name: BIM manager, design technologist, facade specialist, digital fabrication lead, and the structural engineer who wrote the practice's coordination scripts. Contract and consulting work is another channel, since a fair number of these people have been selling this exact service to firms that had not yet decided to hire it in-house.

Closing follows a pattern, and so does losing. The offer dies when the role is described as support: a request queue, no seat in the design conversation, and a director who will overrule an automation because a partner prefers the old sheet layout. It dies again when a candidate discovers the practice expects tool building on top of a full project workload, which is how the last three people in this seat burned out.

Three things close the hire. Give the role explicit time that is not billable to a project, and say how much, because every experienced candidate will ask and most have been promised it before. Name who decides when a script becomes an office standard, and make that path short. And be honest about the software constraint: if the practice is committed to one platform and will not add a licence, say so in the first conversation rather than the fourth. Candidates who have been through a stalled tooling project ask about all three, and the ones who do not ask are usually the ones who have not maintained anything yet. On larger jobs the same appetite for automating the repeated parts shows up on the delivery side, where a digital project controls analyst is doing a structurally similar job against schedule and cost data.

What Does the Seat Cost, and Can It Be Remote?

No wage series covers this title yet, and any single number you find for it is a synthesis of a few postings rather than a benchmark. Price it by the band it hires against: in most practices that is the senior designer or project architect band, and at the top end the same band as a BIM or design technology manager. Firms pulling candidates from software or fabrication usually pay above it, because that is who they are bidding against.

There is a broader wage signal worth carrying into the conversation without over-reading it. PwC's 2026 analysis of roughly one billion job advertisements found an average wage premium of about 62 percent for roles requiring AI skills ². That is an economy-wide average across very different occupations, not a figure for this title, and quoting it as a target is a mistake. It is useful for one narrower purpose: if a partner expects to hire this seat at the standard designer rate because the person is technically an architect, the market is not going to cooperate.

The practical move is to decide the band before the search rather than during it, and to decide what the seat is worth to the practice rather than what the market says. If the automation removes two weeks of documentation from every project of a certain size, that number is knowable from your own timesheets, and it is a better argument in a partner meeting than any published range.

On location, the tool building itself is portable and the role is often posted as hybrid. What resists remote is discovery. The automations worth building are found by sitting near the people doing the repetitive thing, hearing the sigh, and asking what they just did twice. A fully remote specialist tends to build what people request, and what people request is a smaller and worse list than what they would ask for if the automation were sitting beside them. Two or three days on site, with at least one of them near a live project team, is the arrangement most practices land on.

On-premise constraints show up in two places. Some clients, particularly in defense, healthcare and government work, require models to stay inside a controlled environment, which limits which cloud services a script may call and rules out sending model content to an external model provider. And practices running their own compute for simulation or rendering will expect this person to work inside it. Both narrow the pool, so state them in the posting rather than discovering them at the offer stage. Where client data rules are involved, treat the requirement as a legal one and check with counsel in the relevant jurisdiction rather than reasoning from a summary.

See a sample report >