Every few months, I hit a wall. A proverbial wall. Well... sometimes I do actually hit a wall at home but that’s a different story for another time.
It’s the same question that keeps coming back. Should I keep doing what works, or go out on a limb and try something new?
I seem to reflect on this question deeply about 2-3 times a year and I guess it’s that time again.
From years of doing this, I tend to feel this way when I’m bored or when work pushes me to do things I don’t enjoy / want to do. And every time it happens, I feel guilty because on paper, my work is exciting. I know how lucky I am to be where I am now. Still, a part of me knows that something’s off.
But this tension, as uncomfortable as it is, always pushes me to reflect deeply. It forces me to look at the important questions. What do I actually want to do with my life? What does work mean to me? What kind of work excites me ?
I find this ironic, because it’s what I tell people to do all the time. To pause and ask if there’s a better way of working. It’s actually how I teach people to apply computational design to their day-to-day life. I guess I never thought to take my own advice.
Versions of this explore and exploit question actually show up in every facet of our life.
Do you order the same delicious pasta you love or try the new weekly special ?
Should you spend your free time learning more about your work or use the same time to learn a new skill that may or may not be helpful ?
Should you stay in current company and work for that promotion or try your luck elsewhere ?
When it comes to computational design, it’s the same decision. There are some nuances to it but it basically boils down to :
Do I do it the “default” way, the one I know will work? Or do I take a chance on a new approach that might change everything?
With KPIs, deadlines and budgets, I know which option you would choose.
We can jump from planes with only a backpack to save us. Climb mountains where we can barely breath at the top. Dive and swim with the sharks. But nothing scares us more than our KPIs.
The fear of things going wrong is what prevents us from adopting computational design. Even if the “old” way is long and painful. It’s comfortable and predictable. I find that a lot of this comes down to trust. Trust in the tools, in the process, in us as computational designers that we will help you deliver the work.
You have to trust that if you try something new, it won’t backfire on you.
And that’s why I spend a lot of time de-risking new ways of working. I walk them through the process. I show them behind the scenes on how things actually work. All to give people the confidence and trust that computational design works. That they won’t be left alone with a mountain of drawings to send out on Friday. All because they placed their trust in a process that now doesn’t work.
In fact, I promise them hope that things would be better than they are now. They just have to be willing to step back and work with me.
Building that trust and de-risking decisions boils down to understanding the problem first. A point that I have hammered on for ages. But companies don’t work this way. Especially the big ones. Testing new ideas is seen as “non-billable”. Experiments are shunned because don’t fit neatly into project budgets. No company will let you take time out from their already small budgets to test a new method that may or may not work.
Yet, I understand it.
No one wants to be the one who gambled on something new and lost. Why would you take the risk when you have deadlines to meet ? When it’s you who will get yelled at by the client when things go wrong. When come deadlines, I go home while you stay in the office frantically explaining to your manager why the tool I made doesn’t work.
So, the key here then is not more tools or training or even more computational designers. It’s more trust, communication, and understanding.
It’s a very human problem.
Two Things That Always Help
Always aim to understand first
Before doing anything, I take time to understand the problem. Now, project and financial wise, that might not make sense but this is the most important part of computational design. It has to be factored into the project or the cost will come from somewhere (project delays, people working nights, etc.)
And it’s not only about the technical understanding. It’s the context of the problem/project, it’s the people that are already on it, it’s the assumptions and the constraints. It’s taking the time to understand all of that and using it to move forward with intention.
I have heard people tell me that “good leaders make choices based on incomplete information”. While that maybe true, good leaders still strive to find as much information as they can.
If you’re rushing and building things without doing your best to get clarity, it’s always going to go badly.
Get feedback before building
Once you think you know the answer, pause again.
Everyone has a different understanding of the problem and different assumptions. It’s here where we need to find common ground. Because it’s easy to take for granted what we know/don’t know.
Ask the simple and obvious questions:
Is that how they want to work ?
Do they see things changing ?
What will break the workflow ?
Is this even useful ?
While we can’t predict everything in the future, you can leverage the lessons and experience from others to build something more valuable. They maybe able to see something you don’t and that insight is worth all this effort.
It’s all about building a common language with people, so that you are building the best thing you can.
Final Thoughts
Computational design is hard because people are hard. Not only do we have to worry about the technical solutions, we also have to manage the human side of things. Which I argue is the most important one of all, and it’s the part we neglect the most.
As quick as we can build scripts or tools, the real work is earning trust, de-risking decisions, and helping people see that there’s a better way.
Thank you for reading. Consider subscribing if you haven’t, it really helps me know my writing here is useful.