I Built It for the Team. Somehow I Ended Up Owning It.
Creating a tool and owning it are two separate things
I’m on a call with Jack. We’re going through the analysis model for what seems like the 300th time.
“Try reducing the size there, oh and we need to ensure we have the right beam releases. Can you also just put in a simple truss here?”
I am frantically clicking away trying to keep up with the changes that “we” want to make to the model. After about 15 minutes of silence (which is a very long time on a call), I re-run the model and Jack unmutes himself.
“Okay, we are getting closer. Can you try reducing the loads on level 10 to see what happens ? Also, can you add a new freedom case in to mimic the stiffness of the floors ? Let me give you the spring values”
So, I do what he asks and this time, 20 minutes go by before we look at the model and try some other modifications again. None of these are big changes, they are Jack experimenting with different analysis parameters to get the model to work. It’s actually the kind of thing I do with my scripts and programs. He needs to see the results of all these changes to get a sense of the model and to know what to try next.
So, this is what an LLM feels like.
Nothing I do here is computational. Yes, I am learning a lot about what makes a good structural analysis model but is that really the best use of my time here? It might help me write better scripts in the future but right now I’m just clicking where I’m told to.
Jack knows exactly what he wants. He has the structural expertise, the intuition for what to test. . So why isn’t Jack just doing this himself?
Well he has no idea how to use the current program, so I become his hands because I made the script that created the model. And aside from this inefficient way of working, there are two things going on here and they’re easy to confuse because they look the same from the outside.
The wrong analysis program
This entire thing started because of the complexity of the model. Jack reached out because the geometry was impossible to do by hand.
So, I decided that Grasshopper was the best tool to generate the geometry. And at the time, the only analysis program that would work well with Grasshopper was a program called Strand7.
But, Jack was not a good Strand7 user. He knew how to extract data from it and spin the model around, but he could not use it well. I, on the other hand knew the program quite well because of it’s connection to Grasshopper.
Jack reassured me a few times that the analysis we needed to run was simple. It was a proof of concept and that everything could be done through the script. Not manual changing or prodding required. What he needed from me was an understanding of the geometry and some basic loading given his client’s constraints.
Well, the client loved it. But we never change analysis models. The Strand7 model is now really complex. Packed to the brim with freedom cases, restraints, beam end releases, etc. All done manually on the analysis side. In fact, there was little to no Grasshopper work anymore because all the changes and additions we made to the model were normal structural engineering changes.
It was at this point that we should have paused and re-evaluated if this hybrid of computational and manual approach was still the most effective way of working. Where it’s no longer a proof of concept but rather a fully featured structural analysis model that should be managed by someone else.
Because the amount of manual changes that Jack could have done on his own has surpassed the benefit of using Grasshopper. In fact, it got easier to define a split between scripting and manual fixes because we moved from geometry to analysis as the project evolved.
By planning that, we would have come up with a much more efficient way of working. Not to mention the experts in analysis would be able to make changes to the model without having to contact me all the time. I wouldn’t have been on hour long calls with Jack just for him to tell me where to click and what numbers to put in.
And if we ever wanted to bring some scripting functionality back in, I’m sure we would have found a way with Grasshopper. Maybe creating the model in Rhino, then importing it in and applying the loads. At this point, we should have stopped and re-evaluated our options and what it was costing us by staying with this workflow.
Accidental ownership
The second cascading problem to this is me “owning” the model.
Because it came from a Grasshopper script, everyone was asking me to make changes and review them. Me, the person that hasn’t done a lot of structural engineering work and has pretty much rote learned it by making tools for people. Combine that with the fact that Jack can’t use the program well and you have now made a bottleneck. You now have someone under qualified making changes in critical areas.
The ownership of the model became a by-product of using a script and from choosing the wrong analysis program. It’s the part that bothers me the most because accidental ownership is the kind that’s hardest to undo. I can’t one day just say that I am not making changes anymore.
And this isn’t a one-off. I’ve seen the same thing happened a few times. There was this one tool that I build in Grasshopper to run vibration checks and suddenly, I am the “vibration guy”. Everyone came to me for help on why their models weren’t working or why they didn’t get the results they wanted.
just because I made it, I suddenly own the space surrounding it
In both cases, I ended up owning something that should live with someone else.
Hindsight, and the uncomfortable conversation
Maybe it’s the hindsight bias talking, but I should have pushed back more. I should have had this conversation with Jack and ask more questions about ownership and process. Things like who makes the manual changes, should we change programs, or do we need another engineer to help us.
It would have meant asking questions he might not have been ready for or might not have known the answer to yet. “How complex do you think the analysis side will get?” is not a question anyone wants to hear when they’re just trying to get the geometry into a model.
And the real skill is knowing when to introduce friction. When to set boundaries with people.
Pushing back when you’re given work is uncomfortable in the moment. Especially when you always want to go a good job with people. Pushing back creates the friction that slows things down when everyone just wants to get started. It’s hard to be that reason things aren’t moving as quickly.
But the alternative is hundreds of long calls where I am just clicking where Jack is telling me to.
When you’re too busy to set boundaries, that’s when you need boundaries the most.
If you’re about to kick off a project and you’re not sure how automation or computational stuff will fit in then that’s the kind of thing I help people think through. Reply to this email or book a discovery call. Even if it’s just to talk it through and nothing comes out of it, the conversation is free.
Thanks for reading
Subscribe to CodedShapes and I’ll send you my free guide on how to actually apply computational design to your projects.