# Running an engineering process without being an engineer > Source: > Published: 2026-07-25 10:16:01+00:00 I'm not a software engineer. My background is GTM. So now I'm a [GTM Engineer](https://marianomartene.com/gtm-engineer/) I guess. I've spent years helping SaaS founders figure out how to get from founder-led execution to scalable growth. Today, though, I see GTM more as a code problem and spend a surprising amount of time shipping software. The most interesting concept to borrow was the **engineering process**. Programming and engineering are different jobs. Everything I work on starts as a Linear issue. Whether it's a GTM workflow, an internal tool, or a client feature, it goes through the same pipeline: ``` Backlog → Todo → In Progress → Review → Done ``` When an issue is ready, an orchestrator agent picks it up: The interesting part isn't that there are three agents—it's that **every stage leaves its reasoning behind**. Each handoff becomes a comment in Linear explaining what changed, what was tested, and what still looks risky. The ticket itself becomes the audit trail. That completely changed how I work and pushed me toward separating everything into small tasks. I borrowed almost directly from Matt Pocock's workflow: grilling ideas before writing code. Since only 20% of my time is coding, I had to adapt it to work. My flow looks like this: `/grill-me` `/to-prd` Checklists work exceptionally well for LLMs—they force the model not to skip steps. This has probably improved quality more than switching models ever did. **Reserve expensive thinking for Claude Code:** **Everything else runs on open models:** These don't need frontier intelligence—they need throughput. Moving that work onto DeepSeek also let me remove a paid search API because agents could perform the same discovery directly. I stopped thinking about prompting as the important part. **Most quality comes from context.** Everything important about my business lives inside the repository: `CLAUDE.md` — Business rulesEvery new session starts with this context already loaded—lean and on-demand. That means I'm no longer explaining my business over and over. I'm onboarding agents the same way I'd onboard a new teammate, with core context and pointers to their systems (CRM, email, transcripts, etc.). This is a very different workflow from what I imagined AI-assisted development would look like a year ago. I still don't think of myself as a software engineer. But I also don't think that's the point anymore. For me, the most interesting thing was that it gave me access to an engineering process. I'm curious whether other people without a traditional engineering background are converging on something similar. What parts of software engineering have you borrowed? Which open models have earned your trust for high-volume work? My guess is that a lot of us are independently reinventing the same operating system.