Running an engineering process without being an engineer

Mariano Martene — Sat, 25 Jul 2026 10:16:01 +0000

From GTM to Software Engineering: Borrowing Process Over Models

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.

DEV Community: Mariano Martene