In a time when discussions are dominated by advancements in Large Language Models, talking about computational design solutions like a visual scripting library for Grasshopper and Dynamo seems out of date. However, I am still intrigued by the fact that these tools remain indispensable for completing day-to-day delivery tasks and yet are still not integrated into many processes. Despite the vast array of open libraries developed and widely adopted by computational designers, a different reality emerges when these solutions enter the enterprise space.

Enterprises are vast ecosystems that include different workforces, where not everyone is a computational designer. Still, it’s not uncommon to find that 2-3% of people engage with visual scripting at various levels. This number could increase if we consider all potential consumers of visual scripting solutions. With such a substantial pool of users and direct applicability to projects, the question arises: Why is it so challenging to standardise and centralise business logic into libraries or applications that can be consistently used across the organisation?

The more I think about this, the more I return to three main things: management, development, and people. While these things are super important, the people are the most crucial. Let’s see how these points can affect computational design solutions in businesses.

Management

A big challenge in companies is the lack of understanding of what it truly means to develop digital tools. That’s mainly because the old way of doing business, selling time, doesn’t encourage developing digital solutions. In these places, processes are often rigid, prioritising predictability and efficiency over innovation. This rigidity can lead to teams becoming mere order-takers, executing tasks without really understanding the problems they’re supposed to solve. This approach can lead to disempowered teams, where the emphasis on predictability is more important than the need for flexibility and innovation.

Enterprises need to adopt empowered processes that encourage innovation. Approaches like Product Discovery, Continuous Integration and Development, and Outcome-Oriented Roadmaps, when coupled with strategies for implementing reuse—such as Product-line Architectures and Inner Source —can create a powerful synergy. These processes should be designed should help development teams focus on achieving real results rather than just completing tasks from a list.

We see inner source as a way to improve efficiency through code reuse. But even beyond that, it’s an amazing conduit for learning and exchanging ideas and facilitating innovation within IBM.
Jeff Jagoda, Senior Software Engineer, IBM

The true challenge lies in initiating this change. The difficulty often derives from two factors: First, demonstrating the return on investment (ROI) for inner source initiatives can be difficult, particularly in industries focused on tangible, project-based outcomes or where rigid hierarchical structures and a top-down management style impede collaboration and contribution. As John Cutler suggests, the second factor is that instead of calculating ROI based on developer salary or hours saved, it’s more impactful to calculate it based on the value of the work people could be focusing on and the costs associated with delays.

Instead of calculating ROI for developer productivity initiatives based on developer salary (e.g., Xhrs saved at $###/hr), always calculate based on the value of the work ppl could be focusing on and delay costs. For example…. imagine something could be earning a company $1,000,000/mo. Currently, that thing will take 8mo before it earns that. With improvements, it could take 5mo (with potentially better ways to de-risk earlier, test earlier, etc.) The extra hours that are “saved” are likely a drop in the can compared the net effect of increased effectiveness and faster time-to-value (especially when considering multiple $1m/mo efforts).

However, I don’t think the whole company can immediately switch to these changes, even though they could bring many benefits. Instead, a more pragmatic approach might be to set up a dedicated team with its own story, internal business model, and global position within the company. Examples like Haskell’s Dysruptek, 3XN’s GXN, Zaha Hadid’s ZahaCode, or Thornton Tomasetti’s Core Studio demonstrate how creating specialised teams within larger offices can successfully blend innovation with traditional practices. Borrowing Eric Steven Raymond’s metaphor, this approach could allow the “bazaar” to flourish within the “cathedral.” This approach could be more effective than completely transforming everything, reducing risks for the parent company and enabling quicker decision-making.

Just a year ago, at the CDFAM Computational Design Symposium Series, it clearly emerged that almost every AEC design firm struggles to figure out how to fit computational design roles into their organisations. While the industry recognises the potential of computational design, very few firms have a solid plan for how these roles fit into their overall strategy. This challenge is not new. As discussed in this article from Proving Ground, the difficulty in integrating computational design into businesses stems from a fundamental misunderstanding of what computational design is all about. It’s not just about using specific tools like Grasshopper or Dynamo; it’s a whole discipline on its own, generating a different type of value than traditional project teams. Firms must recognise that computational design is an asset across all projects, enhancing the capability of teams.

Computational design must be treated as a distinct business model within or next to the more traditional business models of the projects they’re involved in.
The absence of a clear strategy for developing, maintaining, and sharing computational design solutions remains a significant challenge. In the end, it all comes down to the people in the correct positions, supported by a clear vision and strategy, to overcome these challenges.

Inspired by the original cartoon “Playing it Safe is Risky” by Tom Fishburne.

Development

As developers and tech enthusiasts, we often get wrapped up in the idea of creating the next big thing. The truth is that the solutions with the most significant impact are rarely flashy. Instead, they are the tools that quietly but effectively solve real problems, often without fanfare. The reality is that most advancements that truly move the needle are not particularly sexy—they’re functional, practical, and designed to enhance productivity in ways that may not be immediately obvious.

Take, for example, the yellow line in sports broadcasting. It’s a simple innovation, yet it revolutionised how viewers understand the dynamics of a football game. It’s not just about what we can create but how that creation enhances the user’s experience. This is where storytelling becomes essential—not just to make technology more accessible but to engage users in a way that drives meaningful adoption.

Works with leaders and their teams to craft and deliver narratives that inspire change
David Honigmann

It’s not enough to build something technically brilliant; we must also communicate its value in a way that resonates with the users. Doing so ensures that the tools we develop are not just another tick on a task list but are genuinely valuable, usable, and feasible solutions that align with our business goals.

Unfortunately, many organisations do not develop tools with a product mindset. We focus too much on what’s shiny or cool rather than on solving the real issues that users face. This disconnect often leads to the creation of technologies that are impressive on the surface but fail to provide real value. To avoid this pitfall, we must shift our focus from output—what we can produce—to outcome—what we can achieve that actually matters.

A part of this shift involves understanding and mitigating the “Four Big Risks” in product development:

  • Value Risk: Are we building something that customers want and are willing to ‘pay’ for?
  • Usability Risk: Can users easily understand and use the product?
  • Feasibility Risk: Can we build this solution with the technology and resources available to us?
  • Business Viability Risk: Will this solution generate more value for the business in the long run than it costs?

A lot of times, we overlook these risks, which leads to us making tools that are neither useful for people nor easy to use. We don’t develop with the end-user in mind; instead, we often prioritise what’s possible with the technology rather than what the business and its customers need. This is where engagement with internal users becomes essential. If we measure the results of what we develop or actively seek feedback from those who will be using the tools, we can create solutions that meet their needs. Most projects fail because people aren’t involved.

People

Businesses are ultimately made by people. The people drive innovation, adopt new processes, and ultimately determine the success of any technological or cultural shift. By having the right people in place, companies can confidently deploy new processes or technology with complete team buy-in.

Steve Jobs said at the 1983 International Design Conference in Aspen:

…first thing we do is we’ve always tried to hire people that were much better than we needed for the current job because within six months they’d be fighting to keep up with it second thing is we hire people to tell us what to do … those people are very independent thinkers and what they want is they know what to do what they want is the environment where they don’t have to convince 30 other people that it’s the right thing to do…

However, in many organisations, this is often different from the type of playground in which Digital Leader and developer teams are invited to play. On the contrary, they usually find themselves in environments where they have to constantly justify the value of computational design processes or the need for standardisation and reuse. Instead of being encouraged to innovate, they’re stuck in a cycle of presentations and explanations, trying to get buy-in from leadership.

A significant gap exists between developer teams and leadership, leading to many solutions not getting used, being abandoned, redone multiple times, or not implemented at all. The problem is that different people have different concerns. You and your manager might be looking at problems from different angles or completely different issues altogether. Your solution might not work for them because you’re not both trying to solve the same problem. In my experience, transparency and good communication are the keys to successful collaboration. When in doubt, over-communicate. The more goals, plans, and strategies are shared across the company, the more context everyone has for their work. This transparency brings teams together, gives individuals the power to take the lead, and helps the company reach its goals.

Funny enough, there is also another gap between developers and end users. It’s surprising how often I’ve heard computational designers wonder why they should use an internal solution. The ones you consider your allies—your first customers—are the ones you will spend more time convincing.
This resistance often comes from a lack of communication—explaining the logic behind these tools and making the end-users feel involved in the process. After all, internal users are also customers; like any customer, they need to be convinced of the value of what they’re being asked to use. This challenge is even more complicated by some factors that I am sure you experienced:

  • The “not invented here” syndrome seems to be quite diffuse between developers and engineers, to the point that many professionals are suspicious of the quality and maintainability of any solution they didn’t personally write.
  • Scepticism about ‘external’ contributions: Some may believe that developers outside a team are less skilled or will submit lower-quality code. Ironically, this scepticism can result in a preference for external open libraries simply because they’re “approved” by a broader community.
  • Siloed teams: Organisational structures or team leaders may discourage cross-team collaboration and knowledge sharing. I never believed I could experience this, but it took one year, with different escalations, to get a code internally to be shared.
  • Resource allocation: Product managers or team leaders might not prioritise contributions like testing or feedback. These tasks often get ignored when it comes to project budgets, making them outside the project’s scope.

Collaboration within enterprises remains a significant challenge. The project-based business model often does not encourage collaboration, as individuals may perceive it as detrimental to their career advancement. The “I did this” mindset is still a reality, fueled by a lack of open, honest communication channels across teams and departments. When there’s no trust, collaboration falls apart. Without well-defined shared objectives and a willingness to integrate new tools, the company can feel like a political battleground, more like a plot from “House of Cards” than a cohesive team working toward common goals.
Despite these challenges, people remain the most influential factor in making the “impossible” possible.

Conclusion

Businesses often face common challenges such as prioritising short-term gains over customer loyalty, favouring grand ideas over iteration, tolerating disruptive egos over team culture, focusing on output over meaningful outcomes, getting lost in engineering efficiency, neglecting to empower teams, failing to adopt a product mindset, and lacking a collaborative culture and the tendency to demand innovation without allocating the necessary time and resources to nurture it.

Recognising these patterns is the first step toward overcoming them. Learning from others’ experiences can help businesses navigate these obstacles and drive significant, supported innovation. As the manufacturing industry constantly reviews its processes to improve them, now is the perfect time for the AEC space to do the same!

Utilization and margins driving need for process improvements and new software.
Patric Hellermann, investor in the AEC, Practical Nerds podcast.

Many processes should be improved through computational tools, thinking, and people; knowledge and awareness are mature, but it’s crucial to integrate them more into the overall business strategy.

A huge thank you to Amar and Ben for their invaluable support.