I did a retrospective with only myself before Christmas for some data architecture projects I did last year.
The trigger for it was an extended conversation with a colleague who was quite a mirror for me. The colleague was enthusiastically showing me a stack he has come up with. And it was impressive work. But since I was the one who got the presentation (instead of me doing the presentation), I recognized a flaw in his architecture and saw that I often have the same defect.
With empathy, we can transport ourselves to other persons’ views and situations, but it is hard, and it has to be done intentionally. But often, in projects, that gets lost somehow. Time pressure and a massive load of information generate so much noise that it is hard for us to take a step back.
But we need to take a step back when we want to prevent the thing I call: The nerd trap.
Everyone who is into technology loves tinkering, building new things, the challenge to solve something complex, learning something new, automating things, and short cut with our magic hands on the command line.
This mindset causes a common mistake: We assume that everyone is like that. But they are not.
When we work on solutions, we judge the parts that need tinkering, testing, building, and refactoring with a small impact. Because we like these parts and we solved them before and will solve them again and again. It’s part of our joy and our job.
But there are more people out there who hate the parts that don’t work out of the box. And it’s not they don’t love tinkering and some challenges. They have other jobs to do, tinker, test, and refactor, and the parts that don’t work out of the box are blocking them from moving forward.
Tech can often be seen by different layers that are built on top of each other. Like programming languages from binary code up via C++, Python to “no-code “interfaces. You have most of the freedom in how you build things on the ground layers, but you have to lay a lot of groundwork. On the upper levels, you have less space to do all things the way you intend them to be, but a lot of stuff works.
People in Product, Marketing, Sales, or other similar departments work on the highest level of a tech stack because they have other things to achieve, and they want their tools to work.
So, what was my mistake?
I created well-designed architectures that fit well into the technical requirements we had. And they were cost-efficient. Often significant concerning other solutions.
But they only work smoothly when a similar person or I am involved in the setup. The moment no nerd is on board, these setups develop problems.
Therefore I now have a question in my projects where I ask myself: Is there someone who can take care of the nerd stuff? And if not, is there a solution that works more out-of-the-box than the most efficient one.
And I also show this to my customers that there is a technically ideal solution that best fits their setup. So they understand why we don’t do all the nerd stuff but sometimes settle on solutions that don’t give all freedom but work for the significant use cases.