Why Turner Fleischer Is Embedding Software Developers Inside the Studio
Moving the team from “What should we build?” to “Why does this process exist?”
This conversation is with the Turner Fleischer team behind the firm’s in-house software development initiative — an effort that embeds developers directly inside the architecture practice. The interview was with software development lead Daniel Naughton and digital practice manager Artyom Savin. Responses have been lightly edited for clarity and are attributed to the team collectively.
Turner Fleischer is a semi-finalist for the AEC Innovators Award. You can vote for them and learn more about the award at kpreddy.co/aec-innovators.
You’ve written about embedding software developers directly inside the practice. What was the conversation that shifted your developers from asking “what should we build?” to “why does this process exist?”
When we first started developing software in-house about six years ago, we were primarily order-takers. Someone would come to us and say, “We need to replace this spreadsheet with an app,” or “We need to automate this process,” and we would build it and deliver it.
But once we delivered those tools, they gave us visibility we never had before. When people actually started using them, we could see how they were interacting with them — and we discovered that people weren’t always working the way they described in meetings or documentation. Anywhere a tool had flexibility, people leveraged it to customize. Wherever it had constraints, they found workarounds. What we learned is that the purpose of a tool is defined by how people use it, not by how we designed it.
After that, our discovery process totally changed. Instead of assuming that what came to us was what we should build, we started asking: what problem are we actually trying to solve, and why does this process even exist? A lot of what was being brought to us was constrained by the limitations of existing software — and when you have in-house developers, almost anything is possible. So the challenge today, and where we’re focusing our effort, is getting people to imagine the ideal workflow — blue sky, anything is possible — and then actually agree on it firmly.
Walk us through a recent build-versus-buy decision where you chose to buy instead of build.
We focus on two factors when evaluating build versus buy: how well does it meet our needs, and is it more cost-effective than building it ourselves? The important thing is that it’s not a one-time decision — it’s something we continuously revisit.
A few areas we’ve moved toward buying: parametric design automation, building performance analysis, and Revit productivity. A few years ago there wasn’t much market maturity in those spaces, so we invested quite a bit into building those tools ourselves. Today the landscape has changed and the commercial products are significantly more capable.
That doesn’t mean building them was wasted effort, and it doesn’t necessarily mean we sunset them — many are still maintained and fill a niche. But it changes where we choose to invest our development effort. Instead of competing with commercial design tools, we’re now focused on the gap between practice and business operations — connecting project delivery, operational data, and decision-making. That connectivity is specific to how our firm operates and the specific tech stack we have. One of the questions we ask ourselves is: what’s the secret sauce of how we run our business, and do we really want to compromise that with off-the-shelf tools?
How does the emergence of AI tools change that calculus?
When we’re evaluating AI tools, sometimes what we’re seeing is primarily a front end connecting our documents to an LLM. For a firm that has software developers, that’s not a high technical barrier. So if a product wants to make it into our tech stack, the value proposition has to be much better than that.
How has embedding developers into the practice changed your thinking about where AI can responsibly enter the studio workflow?
There are two facets to this. The first is less technical but quite interesting to us as a firm: we put a large emphasis on our developers building a genuine theoretical understanding of artificial intelligence — which mostly means machine learning, because that’s what most of AI is. That lets us disseminate that knowledge studio-wide through a formal course we teach at our virtual academy, a practical introduction to artificial intelligence. We want everyone in the studio to have a working proficiency: when I put a prompt into a large language model, what is it doing under the hood? What are the limitations and risks? And what workflows can our domain experts on projects come up with?
The second facet is that AI puts an interesting spin on a problem our industry already had: data connectivity. In AEC, we’re forced into a microservice environment — not unique to our industry, but what is unique is that we don’t get a choice. There are all these platforms doing very niche things for a very complex industry, and each has its place. Microservices aren’t new technology, but what’s new for us is that we don’t own the services, so we don’t get to choose how they communicate — unless you have in-house developers to take care of that.
AI hasn’t removed the barriers between those data silos; it’s really just illuminated the fact that they’re there. Large language models make it easier to query your data — instead of writing software or SQL, you can ask in natural language. The bar to entry has dropped, so now people are saying, “Hang on — I want to cross these two silos and give the model that whole context. How do I do that?” There isn’t really a platform that does that well, in a mature way that’s aligned with your business.
For us, software developers handle that orchestration layer. We were always handling the data connectivity problem; now the question is whether we can connect that data and give our agents the full context they need for a workflow, not just context from one silo. We’ve seen it at conferences — many firm leaders saying, “That’s great, but how do I get this agent to talk to all of my data sources?” That’s the real problem now. Because our developers are embedded in the studio — we’re in the rooms when we’re defining how the studio should work and why — we can solve it with intrinsic knowledge of how we work. It’s enabling us to get agentic with the workflows we already have.
Has any of this surfaced operational blind spots leadership didn’t know were there?
Yes — many. And that’s not a Turner Fleischer problem; it’s an industry-wide problem.
We talk a lot about data in this industry, but nobody ever puts a definition to it. The one we like: data is the footprint of your knowledge — the output of your thought processes. If you can look at enough data that’s the output of someone’s thought processes, you understand how they think and how they work. That’s really what machine learning does, except it’s a machine doing it.
Because we have custom applications, our data is structured and queryable, so we can ask questions of it — and we do, on a weekly cadence. How are we budgeting? How are we delivering projects? How are we planning them and scheduling our resources? In real time, you understand at any moment how the studio is thinking. That creates a very fast feedback loop to leadership: this is how we’re actually working — is that how we should work? Then you can course correct, or leadership can update their view, because ultimately the people on the ground are the ones finding the most effective and efficient ways to work.
It’s always illuminating blind spots, and we’re very lucky that leadership wants that. They say: bring it to us, illuminate them, and we’ll figure out whether we need to realign or change our view. The gold standard for any studio should be that you can ask questions of your data at any moment — if someone asks you to pull up your laptop and answer a question, you should be able to do it with data-driven insights. That’s what we’re working toward.
How do you know when a tool needs to be redesigned versus retired?
There are two simple questions — easy on the surface, harder to answer well. Does a tool need to be retired? Ask: do you still do the process it supports? If no, retire it. If yes, the question becomes: does the tool actually align with how you work? If not, redesign it.
Answering that follow-up is where it gets harder. Most software released by commercial companies fails because they don’t have access to their users — they’re begging for feedback on how people work. When you’re in-house, everyone is on your doorstep. You can sit down with users, find their pain points, catch the moment someone says, “Oh, this bit’s annoying.” That’s a sign the tooling is fighting them and needs a redesign — or that they’re not working with the company process, and that’s the source of the friction. Either way, an in-house developer is positioned to understand which it is.
The retirement question is also easier in-house. You can quantify usage metrics, but fundamentally you can also just talk to leadership: is this a process we still want to support as a business? Do we want to change the business rules or enforce certain processes? If so, we should codify them. A well-designed tool is always enforcing the business process — which means your data is always representative of what your business wants it to be.
What’s the biggest resistance you ran into getting non-technical staff to trust developer-built tools over commercial software?
Interestingly, this hasn’t been a significant source of resistance for us. Trust concerns aren’t really the divide between developer-built tools and commercial software — it’s about what the tool is claiming to know.
Take energy analysis. If an ArchViz platform develops a really competent energy analysis visualization tool, people are still unlikely to trust it, because they have energy consultants with specialized software who take professional responsibility for those results. Cost estimation is another example. It’s not just a question of whether we can produce these results, but whether we should, given the structure of our contracts and professional liability.
The questions we ask: can the results be independently verified by a person? Do they carry professional liability? Are outputs reviewed before decisions are made, or accepted at face value? Those factors drive how much effort we put into proving a tool’s reliability. With traditional software this has been much easier because it’s deterministic — input produces output, easy to explain, validate, and audit. AI is fundamentally different. It’s predictive, a bit of a black box, and that raises the bar for validation and trust. That’s where we’ve seen the trust divide happen.
There’s also a reciprocal benefit to being embedded. When you have a problem with commercial software, you submit a ticket and it goes up into the ether — when are you getting a response? Here, our users are two steps away from the software developers. And when they see the rich discovery process we run, by the time a tool launches, everyone’s bought into it.
What’s the single most important thing about the initiative that doesn’t show up on the deck or the website?
We always thought that when we talked about having in-house developers, we’d be talking about the tools. It’s really not about the tools. It’s about how developers are embedded into the studio and the continuous feedback loop that creates — the apps impact the business, and the business impacts the apps. Not being order takers has been transformative.
AI has made the data connectivity problem more obvious, but it’s also made it more obvious how valuable your data is. Every business decision generates data, and it’s only useful if it’s structured, connected, and governed. Garbage in, garbage out. These aren’t IT questions anymore — they’re business questions, because data is the institutional knowledge of the studio. Leadership now wants to understand: where should the data live? Who owns it? How is it structured? Can it connect to other systems? Are we authoring it in only one place?
Ultimately, the goal isn’t to build software. It’s to build an organization that continuously develops digital capability. Firms will say, “We’ve done a thousand of these” — but if they try to query how they actually worked across those thousand projects, and their data isn’t structured and connected, they can’t answer. They can’t tap into that experience, especially without the one person in the room who holds all the tacit knowledge. Institutional knowledge retention means past records of all the knowledge you’ve ever had, not just the collective knowledge in the room right now. And that lives in the data capture.
Whose job does that become — organizing the data, making the governance calls?
It’s such a grand problem that it cuts across many domains of the business — governance, data structure, connectivity. You can have several people wear many hats or many people wear one hat, depending on your maturity. If you’re smaller, people wear multiple hats; a large consultancy probably has specialists each contributing a piece toward the unified goal.
For us, we have a knowledge management department that drives change management with digital practice and contributes to how our data should be structured, where it should live, and whether we can orchestrate across silos. And we have leadership bought in — governance doesn’t stop at the studio; clients have their own governance needs, and depending on who your clients are and what line of business you’re in, that will drastically shape things.
Most people we speak to in the industry who are trying to tackle these same problems are blocked by not having thorough leadership buy-in — the right budget, and the belief that it’s going to return quality, usable information that improves the business. We’re very lucky at TF that we have that.
As an industry, we’re in the era of chopping through the tall trees — forging paths, and eventually we’ll converge on an equilibrium of what’s actually appropriate. Professional liability in AEC is so much higher than in most other industries. You can throw AI into most platforms elsewhere and it’s no harm, no foul — but here, there can be lives on the table, financial ruin, so much at stake. We have to be cautious. But with an aging workforce, aging infrastructure, and the need for more AEC work, we’ve also got to be innovative. You’ve got to be in it, and you’ve got to be careful — both at once.