I thought becoming more technical meant changing careers

I’ve spent the past six months becoming more technical at work, driven by problems I kept running into and wanted to solve myself. At first I assumed that meant carving out study time again: documentation in the evenings, a course or two, side projects after hours. Getting closer to engineering looked like something I’d have to do outside my job. That isn’t how it went. I stopped treating every problem as someone else’s to solve, and the rest came from there.

When I started studying telecommunications engineering, I had a clear picture of where my career was heading. I expected to work on networking systems, simulations, maybe research. I liked understanding complex systems, working out why they behaved the way they did, and solving technical problems.

Instead I joined Framer as a contractor while I was still at university. I loved the work, stayed after graduating, and moved into a full-time role. My responsibilities shifted over time towards product, operations, and then leading the Marketplace. My days filled up with creators, moderation, policies, launches, and the challenge of making a marketplace work for thousands of people.

I enjoyed that transition. Somewhere along the way I also picked up an idea that turned out to be false: becoming technical again would mean changing careers, and building things was something I’d left behind.

The culture I’ve appreciated most at Framer is the one around ownership. You aren’t expected to ask whether a problem belongs to you or your team before working on it. If you see a way to improve something, you explore it. Sometimes that means writing code, other times redesigning a workflow or questioning a process that’s been running untouched for years. The expectation is that you own the things that get in your way. That mindset had been reshaping how I worked long before I noticed it.

Running the Marketplace means hitting friction all day: a report that takes twenty minutes longer than it should, a moderation workflow with one manual step too many, the same question coming back every week because the dashboard that would answer it doesn’t exist. None of it is exciting, and none of it justifies pulling an engineer away from work with a much bigger impact. For years my response was the same. I’d open a Notion page, explain the problem as clearly as I could, and move on. Then I started asking whether I could build it myself.

I never sat down with the goal of learning SQL, Retool, TypeScript, or how to contribute to a large codebase. Each one arrived because a problem demanded it. I wanted better visibility into Marketplace data, so I refreshed my SQL knowledge until I could answer my own questions. The team kept asking questions a dashboard could answer, so I learned Retool while building one. I was repeating the same operational work every week, so I worked out how to automate it. Feature requests became pull requests. No learning plan produced any of this. I was solving problems, and the technologies came along for the ride.

The process also got cheaper. I open Cursor, build a rough first version, work out what it’s doing as I go, and ask questions when I get stuck. Five years ago I’d have spent an evening reading documentation and convinced myself I wasn’t ready to write anything. Now I get something running in an afternoon. Most of those first attempts are rough, which is fine. I need to get far enough that someone more experienced can point me in the right direction.

The part I didn’t expect is which of my old skills carried over. Months of writing feature requests, bug reports, moderation notes, and internal documentation turned out to be the most useful preparation I had. A prompt works like a ticket: context, constraints, and a concrete goal. The better I describe the problem, the better the help I get back, whether the reader is an engineer or a model. All those years of explaining Marketplace problems to other people taught me the skill I now use to explain them to Cursor.

That also changed my conversations with engineers. Instead of asking someone to build an idea from scratch, I ask them to review something that already runs. Those conversations are better for everyone involved, and I’ve learned more from them than I would have from the sidelines.

My job hasn’t changed. I spend most of my time on creators, moderation, Marketplace strategy, and product decisions. What moved is my default reaction to a problem. Six months ago I opened Notion. Today I open Cursor. Sometimes I still write the page, and sometimes I get far enough in to realise I need help. Often enough, I ship something that saves time or makes someone else’s job easier. The outcome matters less than the fact that I stopped assuming I couldn’t contribute.

Becoming more technical came down to changing my first question. I used to ask who should build this. Now I ask whether I can.