Running an engineering process without being an engineer

I'm not a software engineer. My background is GTM. So now I'm a 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.

• Cloudflare Workers
• Internal tools
• Lead scoring systems
• Client microsites with databases behind them

The most interesting concept to borrow was the engineering process. Programming and engineering are different jobs.

The Process Matters More Than the Model

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:

• One agent builds it
• Another reviews it
• A third only deploys if the reviewer explicitly approves

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.

Grilling Ideas Before Code

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 - Pushes back on every assumption, looks for missing requirements, edge cases, and contradictions
• /to-prd - Turns the conversation into a proper specification and publishes it as a checklist of implementation tasks in Linear
• Code - By the time an agent starts writing code, it's working from a document, not a prompt

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.

Frontier Models Should Make Decisions

Reserve expensive thinking for Claude Code:

• Orchestration
• Architecture decisions
• Code review
• Business logic
• Anything where judgment matters

Everything else runs on open models:

• Bulk enrichment
• Classification
• Scraping
• High-volume work

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.

Context is Infrastructure

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 rules
• Architecture notes
• Reference documentation

Every 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.).

How My Days Break Down

• GTM work - Lead sourcing, enrichment, ICP scoring, outbound systems
• Client software - Small production apps, review microsites, internal tools
• Content - LinkedIn posts, newsletters, articles
• Internal tooling - Tools only I use
• Plumbing - APIs, automations, integrations

This is a very different workflow from what I imagined AI-assisted development would look like a year ago.

Final Thoughts

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.