Building a Design Technology Function from Scratch — Hayball

Topline

Hayball, a 200-person architecture practice across Melbourne, Sydney, and Brisbane, had no design technology capability in 2018. By 2022 it had a five-person team, a suite of internal computational tools in daily production use, integrated AR/VR review workflows, and 30–40% efficiency gains on the documentation-heavy workflows the tools touched. I was hired to be a Grasshopper person. I left having built the function.

Context

Hayball is one of Australia's largest architecture practices. Education, residential, urban design. In 2018 the firm's relationship with technology was the standard one: BIM as documentation, Rhino as geometry, everything else as manual labour. Feasibility studies took days of manual massing. Solar and radiation analysis was outsourced or skipped. Knowledge about how to do things lived in whoever had done it last.

There was no mandate for a "team." There was a job ad for one person who could script.

The brief

"We keep losing time on things that feel automatable. Can you help the design teams work faster?"

The constraint nobody mentioned: architects do not adopt tools that interrupt how they already work. Any tool that required leaving Rhino, learning a new interface, or trusting a black box would die in a week. Whatever got built had to live inside the workflow it was replacing.

What I actually did

1. Shipped one tool that mattered before asking for anything

The first build was a real-time radiation analysis tool: solar and daylight feedback directly inside the design environment, replacing an outsourced analysis loop that took days with one that took seconds. Design teams could see the consequence of a massing move as they made it. That single tool did the political work: it made "design technology" a thing partners could point at.

2. Built the toolchain around real bottlenecks

With credibility banked, I mapped where design time actually went and built against the top of the list:

• Rapid Feasibility Tool. Urban massing and yield studies that took days reduced to parametric studies that took hours. Site in, envelope options and yield numbers out.
• Facade Design Tool. Parametric facade generation and documentation, closing the gap between design intent and buildable panel schedules.
• Radiation Analytics. The real-time environmental feedback loop, extended across projects and building types.
• ML pipelines. Early machine-learning experiments on design data, years before the industry started calling everything AI.

Every tool shipped with the same rule: it lives where the architects already work, or it doesn't ship.

3. Hired and scaled the team

One person cannot support 200. I made the case for headcount with adoption numbers, not vision decks. The function grew to five people across the three studios, with a shared codebase, internal documentation, and a support model. The team structure survived my departure, which is the only test of an organisational build that counts.

4. Ran the firm's digital transformation as change management, not IT

In parallel with the computational work, I led the internal transformation off legacy tooling: communication scattered across Skype, email, and corridors; files in fragmented systems; knowledge in personal folders. We consolidated onto an integrated collaboration stack, phased the rollout through internal champions, and documented standards so the systems outlived the project.

The unglamorous dividend: when 2020 forced the entire practice remote in a week, the systems were already in place and adopted. Business continuity was a side effect of work done before anyone knew they'd need it.

5. Built the external technology relationships

I led the strategic partnership with Unity (integrating real-time 3D and AR/VR review into design workflows) and represented the practice's digital work publicly, including Sydney Build Expo and the Global XR Conference. The partnership work mattered internally too: it signalled to the firm that this capability was strategic, not support staff.

What broke

Plenty. The honest list:

The first version of the feasibility tool was too clever. It optimised for parametric completeness. Every option, every parameter exposed. Architects wanted three good options fast, not three hundred configurable ones. I rebuilt it around defaults and cut the interface in half. Adoption followed the second version.

I initially tried to train everyone. Firm-wide Grasshopper training sounded like leverage; it was actually a distraction. Most architects don't want to script. They want tools that work. The pivot: train a handful of power users per studio deeply, give everyone else finished tools. Training time dropped, adoption rose.

Some tools died. A generative layout experiment never earned production use because it answered a question the design teams weren't asking. Shipping it taught me more about tool-market fit inside a firm than any success did: internal tools have customers, and customers can churn.

Outcomes

What changed for the firm

Before: technology decisions made ad hoc, analysis outsourced, feasibility manual, knowledge personal.

After: an in-house team with a shared codebase and a mandate, tools in the daily workflow of three studios, a practice that could evaluate and adopt new technology with its own judgment rather than a vendor's. The capability compounds: every tool the team ships now builds on infrastructure laid then.

That is the difference between hiring a scripter and building a function. The scripter's output stops when they leave. The function keeps shipping.

The handover

A five-person team with its own leadership, a documented internal codebase and component library, tool documentation and training materials, and transformation standards embedded in practice operations. Nothing depended on me by the time I left. By design.

Engagement shape: full-time Design Technology Lead, 2018–2022, Melbourne/Sydney. Team built from 1 → 5 across three studios.

Related: the adoption lessons from this work carried directly into the Bollinger Grohmann Knowledge Hub, and into the essay Why AI Pilots in AEC Die in Month Two.

Want this kind of capability built inside your practice? Start with a Pilot.