Positioning computational designers in your business: 4 things to consider

The term computational designer has garnered considerable attention from both recruiters and job applicants in recent years. We can read this as an interesting indicator that design organizations are actively looking at new skillsets to evolve their process. However, for all the hype around this new role, there appears to be very little industry consensus as to what a ‘computational design’ position actually means in a business setting.

This comes in stark contrast to many other roles for which architecture and building teams are used to recruiting. For example, the role of ‘architectural designer’ is a very known commodity to architecture companies. We can assume that individuals have a specific academic background, commonly possess (or are working towards) a license, and are able to work with others to satisfy project design requirements. We can assess an architectural designer’s ability by reviewing their portfolio, discussing their sensibilities, and reviewing their previous studio experience.

In the context of more technically-inclined roles, BIM-related job requirements  are also fairly well understood in the building industry. We can align them with criteria for both technical knowledge and the ability to execute a specific project delivery process. We can assess an applicant’s  technical capabilities with specific software and review his or her past deliverables and execution plans.

So, what about the computational designer?

I have had colleagues describe this role chiefly in terms of specializing in geometric complexity. Some of my clients have discussed it in terms of automating project design studies and creating variations. A recent ArchDaily article has aligned computational design with knowing a specific ‘visual programming’ software such as Grasshopper or Dynamo. All of this is to say nothing of the very limited academic field on the subject. Relative to other architectural studies, only on rare occasions will you meet someone with an academic degree or research credentials specific to the subject of computational design.

So where does that leave an architecture business that is actively looking to add a computational designer to the team? Here are three things I encourage my clients to consider when building a team…

1. Computational Design != Technical Role

While computational design is made possible by technology, it should be thought of first as a problem-solving methodology. To put it another way, think of a computational designer like a designer using a very different medium.  A computational designer should be able to describe the design problems they have encountered projects and how they developed the computational workflow to aid in their resolution.

With that said, I often see businesses make the mistake of lumping computational design in with the same technology departments that may provide technical support or training. “We need more people that can support and teach Grasshopper!” is a common refrain I hear from leaders and managers. I advocate for a different approach, and instead  recommend that the company consider the role from a design-centric perspective first, much they would for any applicant who  would join their project team.

Like any designer, a computational designer should be able to reflect on the value of their methodology and explain how their method produced more desirable results for the project and the team.

2. Computational Design != BIM

There will surely be many opinions on this subject especially as buzz phrases like “Computational BIM” have come into fashion. While perhaps obvious, I will state unequivocally that computational design is not BIM. BIM is also not computational design. That is not to say they are incompatible processes. Nor is this to say that when thoughtfully combined they cannot greatly enhance a design workflow.

Rather I see them as very distinct capabilities that can deliver value on their own merits. While computational design and BIM often leverage the same or similar digital media, the requisite professional expertise, methodologies, and process objectives are very different. The concepts are so different that their respective job requisitions should  attract vastly different applicants.

I was recently in a strategic workshop to help clients define some new office roles. They were very excited about the idea of having a computational designer in their company because several of their competitors were touting this capability. After describing the role a bit, one of the participants asked me if a computational designer could also work on BIM standards or help create Revit families? Several of the other individuals quickly nodded in agreement. “We definitely need that kind of person.” another chimed in. “They’ll support BIM, too, right?”

My response was simple: “A computational designer is going to bring a different methodology to a design process and may not even apply to an open BIM-related job opening. Perhaps we should focus on also defining a role for a new BIM leader.” The participants agreed that two positions should be discussed… while also realizing that the world of technology in architecture was becoming more complex than they previously understood…

3. Computational Design != Everyone

As I was giving one group of executives an overview of some of our computational design work, one executive chimed in: “This looks really powerful!” he remarked, “How can we get our entire staff to start using this process? Do we need Grasshopper training?” The assumption was clear: As with with CAD and BIM packages, a week’s worth of training and maybe some technical support would turn their office into a computational design shop.

There is no doubt that computational design is becoming more commonplace in offices. Younger professionals have had exposure to the tools in their academic career. But the fact is that it is not for everyone. Would a company expect that all architecture staff learn how to be project managers? Or go into business development? Anyone who has instructed a Grasshopper workshop to a team knows that few participants naturally gravitate towards the computational design, and even fewer take it seriously enough to make it a core part of their career path.

As I have mentioned in previous articles, I have found it to be more productive for a company to think about how a range of skillsets can be built up over time. For project leaders and general staff, an awareness of the capability and its relevance to the process is important. For advanced implementation, the company could focus on hiring or partnering with an expert in the field.

4. Computational Design = Solutions

Because computational design is a relatively new concept to the building industry, experience levels are going to vary greatly. Computational design applicants to your business may range from young professionals that are just out of school, to technicians who have been working in the industry for many years. It is easy to misjudge capabilities if you base your hiring decision on if they are listing certain software on their resume or if they have projects in their portfolio that look computational.

In my view, the best indicator you have found the right fit for your team will be in how well the applicant can convey their thought process, and that it aligns with your aims and values. Ultimately, they should be interested to learn about the design challenges specific to your firm and describe a computational vision that can help lead your business to the best possible solution.