I didn’t start in tech with a Computer Science degree or engineering background. I got into the industry by chance, armed only with a background in psychology and for a long time, that meant I spent meetings with developers feeling completely out of my depth.
But over time, things changed.
Today, I’m able to visualize how features might be developed, assess technical feasibility, and even help identify solutions for product and engineering problems. I’m still not a developer, but I’ve built just enough technical fluency to contribute meaningfully in product and tech conversations.
So how did that shift happen?
I started with HTML and CSS. Not to become a frontend dev, but to understand structure and layout. Later, I learned to write simple MySQL queries to interact with data. These foundational skills helped me grasp the logic of how systems work and communicate.
If you’re non-technical and working in tech, learning just enough to inspect code or understand a data model can go a long way.
For a long time, I felt embarrassed not understanding terms that engineers threw around so casually. But I asked anyway. I kept asking until I truly grasped the concepts behind the systems we were building.
Eventually, those "dumb" questions became the backbone of my learning. Asking openly builds trust and it pushes teams to communicate more clearly too.
I consumed tech articles, developer documentation, and any resource I could find that helped me understand concepts like APIs, cloud architecture, and development workflows. The more I read, the more I could connect the dots between product decisions and technical implications.
Even when I barely understood what was going on, I showed up. I joined grooming sessions, sprint reviews, and post-mortems. Sometimes I was just listening; other times I’d ask for clarification or offer a user perspective.
Over time, I learned how engineers think and how to communicate with them on their terms without pretending to be one.
Psychology taught me to listen and understand people’s motivations and struggles. That carried over into how I work with engineering teams. When I understand their pain points such as tech debt, legacy code, unrealistic timelines, I can advocate better, set clearer priorities, and help prevent burnout.
Eventually, I reached a point where I wanted to build faster, more iteratively without being bottlenecked by complex, outdated codebases that made even small changes painful.
In a previous product, we struggled to add new features because of accumulated technical debt. The architecture was rigid, and every enhancement introduced a dozen side effects. It became clear that flexibility, speed, and experimentation were crucial especially in early-stage products.
That’s when I turned to no-code platforms like Bubble and automation tools. They allowed me to translate product requirements into working features myself. I could iterate faster, test ideas sooner, and focus on what really mattered: solving the user’s problem.
No-code wasn’t just a workaround. It was a mindset shift — a way to build strategically with fewer dependencies, without compromising on user experience.
I’m not some technical prodigy. I don’t have above-average intelligence, nor a secret advantage. What I do have is:
If you’re a non-tech person working with developers, know this: You don’t need to become an engineer to be effective. But you do need to develop technical empathy and curiosity.
And most importantly, you need to keep showing up — even when it feels uncomfortable.