What Does a Marketing Engineer Do All Day? One Loop and the Third-Time Rule
A marketing engineer spends the day building and fixing the systems that do marketing work, then reading what those systems found. The week runs one loop: research, build, ship, learn. Most hours go to work that changes how other work gets done.
A task becomes a system the third time it comes up.
What does a marketing engineer do all day?
Two marketers start Monday with the same pile of requests. One answers every request by Friday. Busy week.
The other sees that three of the requests are the same request. She answers it once, writes the steps down and builds a small system. Next Monday it answers itself.
Same pile. Different job. The second one is a marketing engineer.
So what does a marketing engineer do all day? They build the systems that do marketing work, fix them and read what they find. Very little of the week goes to making things by hand.
Want the definition first? Read what a marketing engineer is, then come back. This guide is about the hours.
Here is the answer up front. The week runs one loop: research, build, ship, learn. A task becomes a system the third time it comes up, and what a wrong answer costs decides how much that system runs alone.
Looking for salaries or job titles? Not here.
Those change every year. The loop does not.
One marketer clears the pile; the other shrinks it
| Marketer doing the work | Marketing engineer |
|---|---|
| Answers each request by hand | Spots the request that keeps coming back |
| Same pile again next Monday | Builds the answer once |
| Judged on how much got done | Judged on what other people got back |
| The week ends when the pile is empty | The week ends with one more system running |
Our method, set out in this guide.
A marketing engineer's output is what other people's work produces
The job is judged by what changes downstream, not by what the marketing engineer makes. That idea is older than AI.
Gary Lilien and Arvind Rangaswamy gave "marketing engineering" its first meaning, and it runs through their textbook Principles of Marketing Engineering and Analytics, written with Arnaud De Bruyn. They split decisions three ways. Gut alone is conceptual marketing, a full machine is automated marketing, and judgment plus models is marketing engineering.
Their marketing engineer was a manager deciding with data. Ours also builds the machine: the pipelines, the agents and the tests. That is how the role grew.
Andy Grove gave the yardstick in High Output Management. A manager's output, he argued, is the output of their own team plus the teams they influence. He counted experts with no reports, like market researchers and computer specialists, as managers too.
That is the marketing engineer. Their output is the qualified leads, the lower costs and the hours other people get back. Not the scripts.
Grove's second rule keeps the score honest. Measure output, not activity, and pair every count with a check on quality. A salesperson is judged on orders, not on calls made.
Busy is not a result.
Three ways to make a marketing decision
- Conceptual marketing A person decides from experience alone, with no model or data tool.
- Marketing engineering Judgment plus data and models. A person still makes the call.
- Automated marketing A system decides on its own. It fits where a wrong call is cheap.
Definitions from Lilien, Rangaswamy and De Bruyn, Principles of Marketing Engineering and Analytics.
Pair every count with a check on quality
| What you count | The quality check paired with it |
|---|---|
| Messages sent | Qualified replies |
| Ads launched | Cost per result |
| Pages published | Pages that get search visits |
| Drafts an agent wrote | Share approved without edits |
| Automations built | Hours saved, measured by the team that uses them |
Pairing principle from Grove, High Output Management. The marketing pairs are ours.
The Third-Time Rule decides what a marketing engineer builds next. The first time a task comes up, do it by hand and take notes. The second time, write the steps as a checklist, with one example of a good result.
The third time, build the system: the checklist is its job spec and the example is its test. Then price a wrong answer. Frequent and cheap runs alone with sample checks; frequent and costly drafts for a person to approve; rare work stays a checklist or stays by hand.
Run the rule every Friday on the week's task list.
The day runs on one loop: research, build, ship, learn
Every system a marketing engineer touches runs the same four steps. That loop is what fills the calendar.
Research means reading the raw material before opening a tool: calls, tickets, ad results, search data. Lean Analytics, the metrics book from Alistair Croll and Benjamin Yoskovitz, gives research two jobs. Find the people who do what you want and what they share, then test any change on part of the audience and compare.
Research also covers the whole buyer path, not one department's slice. Bob Moesta's Demand-Side Sales 101 lays out six buying stages, from the first thought to ongoing use. Marketing, sales and support each own a piece, and because they rarely talk, buyers get mixed messages.
A marketing engineer can see the whole path, end to end. In our reading, that is where the role earns its keep.
Build means writing down the job before wiring anything. What starts it, what goes in, what good looks like. Our agent job spec is the template.
Ship means someone else uses it. A script that runs only on your laptop is a hobby.
Learn means every mistake becomes a written rule. The system should never make the same mistake twice.
Growth teams run the same shape. In Hacking Growth, Sean Ellis and Morgan Brown loop through analysis, ideas, ranking and testing, then back to analysis.
Their loop picks experiments. Ours picks systems.
Every system runs the same four steps
- Research Read calls, tickets, results and search data before opening a tool.
- Build Write the job down, then build the smallest version that works.
- Ship Put it in front of the people who will use it every week.
- Learn Turn every mistake into a written rule, and check the number.
Our method, set out in this guide.
Each step ends with something you can hold
| Step | Ends with | Fails when |
|---|---|---|
| Research | A one-page note of what buyers did and said, with sources | You start from a tool, not the data |
| Build | A written job spec and a first version that works | Nobody wrote down what good looks like |
| Ship | A named person using it every week | It only runs on your laptop |
| Learn | One new written rule, and the number checked | Corrections live in someone's head |
Our method, set out in this guide.
Grade the week by output, not by how full it was
A full calendar proves nothing. What matters is how much output each hour creates for other people.
Grove scores every activity that way. He lists three ways to get more from a day: work faster, make each activity count for more, or swap low-value work for high-value work.
Grove names three cases where one activity counts for a lot. First, it touches many people. Second, a short action shapes behavior for months.
Third, one person supplies the knowledge a whole group was missing. A marketing engineer lives in all three.
One job spec shapes every draft an agent writes for a year. One clean data source feeds five teams. Small move, long reach.
Grove left a piece of homework, and it is the best audit of this job we know. Take last week's calendar and mark each block low, medium or high. Then plan more of the high, and name the low block you will cut.
Mike Michalowicz adds the words for it in Clockwork. All work is Doing, Deciding, Delegating or Designing. Deciding is the trap: you hand off a task, then answer every question about it, so the work still runs through you.
The same trap catches automations. If a system needs your answer on every run, you did not delegate anything. You are Deciding with extra steps.
His target for a whole company is 80 percent Doing and 10 percent Designing, with the rest split between Delegating and Deciding. In our reading, the marketing engineer is where much of that design time lives.
The same five activities fill a marketing engineer's day
| Activity | In Grove's day | In a marketing engineer's day |
|---|---|---|
| Gathering information | Meetings, calls, walking the floor | Reading calls, tickets and results before building |
| Giving information | Explaining goals and priorities | Writing the job spec and the rules a system follows |
| Deciding | Deciding, approving or vetoing | Picking the one build for the week |
| Nudging | A note or a comment that steers a choice | A comment on a draft or a test plan |
| Role model | Values shown by doing them | Logging every correction where the team can see it |
Five activity types from Grove, High Output Management. The marketing column is ours.
A healthy company still spends 80 percent of its time Doing
Target share of a whole company's work time, by type of work
- Doing 80
- Deciding 2
- Delegating 8
- Designing 10
Source: Mike Michalowicz, Clockwork, the optimal 4D mix for a company, not for one person.
Grade the week by output, count the repeats, cut one low block
- LOW: the same report, rebuilt by hand again.
- Design time goes first in the week, not last.
- Past its third time. This is next week's build.
- Second time: write the checklist and save a good example.
- Grove's homework: name the low block you will cut.
Example page built for this article with a made-up week, using the calendar grading from High Output Management and the Third-Time Rule. Tasks, times and counts are illustrative.
A marketing engineer's day in the life, laid out as a week
Put the loop on a calendar and it looks like the timeline below. Design comes first in the week, not last.
Michalowicz makes the same call. Block the design time at the start of the week, and the rest of the week serves it.
Monday is for reading. Check what the systems found and which tests can close. A weekly memo does most of this, and we show how to build one in the growth cockpit.
Tuesday is for choosing. Hacking Growth holds its weekly growth meeting on Tuesday, so Monday can be prep.
The meeting runs one hour. Fifteen minutes on the numbers, ten on last week's pace, fifteen on lessons, fifteen to pick this week's tests and five on the idea backlog.
No brainstorming in the room. Ideas arrive already written up.
Wednesday is for building and for sitting with the people who will use the build. Thursday is for maintenance. Most people skip it.
Google's reliability engineers have a blunt test for it in their chapter on toil. If a person has to touch a system during normal running, the system has a bug. Thursday is when you find those touches and remove them.
Friday is for the number. Did the change move what it was meant to move? Write down one new rule, and add any task that came up again to the list.
Wooga, a games company profiled in Lean Analytics, shipped an update every week and aimed each one at a single metric. One number per week keeps Friday honest.
Gino Wickman's Traction explains why the week is the unit. On track for the week means on track for the quarter, and the quarter for the year. He also tells leaders to book a regular hour away from the desk just to think.
Friday afternoon, after the number, is a good home for it.
Design first, maintenance on its own day, the number on Friday
- Read and design Monday Read what the systems found. Close finished tests. Block design time first.
- Choose Tuesday One-hour meeting. Pick this week's one build and the number it should move.
- Build and ship Wednesday Build it, test it on past data, sit with the people who will use it.
- Maintain Thursday Fix what broke. Remove every step a person still has to touch by hand.
- Learn Friday Check the number. Write one new rule. Count repeat tasks. One hour to think.
Our week, using the Tuesday meeting from Hacking Growth, design time from Clockwork and the thinking hour from Traction.
One hour, five parts, no brainstorming
| Minutes | What happens |
|---|---|
| 15 | Review the key numbers and confirm the focus area |
| 10 | Last week's pace: tests launched against the goal |
| 15 | Lessons from tests that finished |
| 15 | Pick this week's tests and give each one an owner |
| 5 | Check that the idea backlog is still growing |
Source: Sean Ellis and Morgan Brown, Hacking Growth, the weekly growth meeting agenda.
If the week is on track, the year is on track
- To-do Done within one or two weeks.
- This week's issues Came up this quarter and must be solved now.
- Quarterly priority Due this quarter, takes weeks or months.
- Yearly goal Must be done this year.
- Long-term list Anything further out than 90 days.
Based on Gino Wickman, Traction, the compartmentalizing rule.
What should a marketing engineer automate next? Use the Third-Time Rule
The Third-Time Rule is our test for what gets built next. The first time a task comes up, do it by hand and take notes. The second time, write the steps as a checklist, with one example of a good result.
The third time, build it. The checklist becomes the system's job spec, and the example becomes its test.
Why wait? Because you can only check work you understand. Grove's advice on delegation says the same: hand off the work you know best, since that is the work you can monitor.
Google's reliability team draws its line in the same spot. Toil is their word for manual, repeated work a machine could do, and work done the first or second time is not toil. They aim to keep toil under half of each engineer's time.
The Accelerate researchers put the split plainly: "Computers perform repetitive tasks; people solve problems." The Third-Time Rule is how you sort one from the other.
Is the build worth the hours? Randall Munroe's chart Is It Worth the Time? does the math across five years. Shave 5 minutes off a weekly task, and you can spend 21 hours building before you lose time.
Shave 30 minutes off a daily task, and the budget is 5 weeks. Most marketing chores sit somewhere in that table.
What stays by hand? Work that came up once, and work that truly needs fresh judgment each time. Careful with that second one: the same Google chapter warns that constant judgment calls often mean a badly built system.
Do it, write it, then build it
- First time Do it by hand. Take notes on every step and every surprise.
- Second time Write the steps as a checklist. Save one example of a good result.
- Third time Build it. The checklist is the job spec. The example is the test.
- Every Friday Count repeats on the week's task list and pick the next build.
Our method, set out in this guide.
How long you can spend automating a task before it costs more than it saves
Across five years. Find the time saved per run, then the task's frequency.
| Time saved each run | Daily task | Weekly task | Monthly task |
|---|---|---|---|
| 1 minute | 1 day | 4 hours | 1 hour |
| 5 minutes | 6 days | 21 hours | 5 hours |
| 30 minutes | 5 weeks | 5 days | 1 day |
| 1 hour | 2 months | 10 days | 2 days |
Source: Randall Munroe, xkcd 1205, Is It Worth the Time? (five-year horizon).
The first and second time are not toil. Repeated work is the build list.
- Thursday's job: find every step a person still touches by hand.
- First or second time: not worth building yet. Do it, then write the checklist.
- Repeated work is the build list.
- Real judgment stays with a person. Check the excuse first.
Screenshot of Google, Site Reliability Engineering, Chapter 5: Eliminating Toil, taken 2026-10-18. Dashed lines mark skipped text.
Before you build it, price a wrong answer
How often a task comes up tells you when to build. What a wrong answer costs tells you how far to trust the build.
Lilien and his co-authors drew this line long before AI agents. Where a wrong decision is cheap, like a product recommendation or keyword pricing, they say automate it. Where it is expensive, like a positioning strategy, keep human judgment in the loop.
We turn that into four boxes, shown in the matrix below. Frequent and cheap runs alone. Frequent and costly drafts, and a person approves.
Rare and cheap gets a checklist. Rare and costly stays by hand.
Approval does not have to last forever. Grove's factory method was variable inspection: check less after weeks without problems, and more the moment problems show up. Do the same with any drafting system.
One more rule from Grove. He objected to a manager who let a new hire learn by making mistakes, because the customers end up paying the tuition.
A new automation is a new hire. Test it on last month's data before it touches a buyer.
To score whether the systems pay off, use the signal card in how to measure a marketing engineer.
How often it happens and what a mistake costs decide how far to trust a system
- Keep it by hand A person does it, with notes for next time.
- System drafts, person approves Build it. Nothing reaches a buyer without a yes.
- Checklist only Write the steps down. Not worth a build yet.
- System runs alone Build it. Check a sample, not every output.
Our matrix, built on the cheap-versus-costly decision rule in Principles of Marketing Engineering and Analytics.
Check more after a failure, less after a clean run
| Check every output | Variable inspection |
|---|---|
| A person reads all of it | A person reads a sample |
| Slows every output down | Work keeps moving |
| Same effort in a good week and a bad one | More checks the moment problems show up |
| The builder stops owning quality | The builder owns quality, the sample keeps it honest |
Based on variable inspection in Grove, High Output Management. Applying it to AI drafts is our reading.
Where a marketing engineer's week goes wrong
Most failed weeks look productive from the outside. Here is the usual playbook.
How to spend a quarter building nothing that runs, in four easy steps:
1. Automate a task you have done once. You do not know its edge cases yet, but the demo looks great.
2. Build five systems at the same time, so none of them gets finished.
3. Skip Thursday. Fixing things is boring.
4. Report how many automations you built, not how many hours anyone got back.
Impressive as hell on a slide. Not one of them runs next Monday.
Want to know which of these your team already does? Run the marketing engineering audit. A yes only counts if you can show the proof in five minutes.
Three stuck points, and the fix for each
| Symptom | Cause | Fix |
|---|---|---|
| The automation breaks on real work | It was built after one run, before the edge cases showed up | Go back to the checklist stage. Build on the third time. |
| You answer questions from your own system | The job spec never said what good looks like | Add the example and the rules. Then stop answering. |
| Systems pile up and nobody uses them | No Thursday, and no named user | One build a week, one named user, one fix day. |
Our method, set out in this guide.
Plan your week with AI: the copy-paste prompt
Paste the prompt below into your preferred AI. It asks about last week's tasks, how often each came up and what a wrong answer would cost.
Then it grades the week, picks one thing to build and lays out Monday to Friday. It never invents hours or costs. You bring the facts.
Paste into your preferred AI. It asks five questions, then grades your week, picks one build and lays out Monday to Friday.
Act as a marketing engineering coach. Help me plan next week with the research, build, ship, learn loop and the Third-Time Rule. Ask me these one at a time, with the example. If I answer several at once, skip ahead. 1. What does the business sell, and to whom? (Example: kitchen remodels to homeowners) 2. List last week's tasks with rough hours. (Example: weekly ad report, 2 hours; pricing emails, 3 hours) 3. How many times has each task come up so far? (Example: ad report, 6 times; pricing emails, 3 times) 4. If a system got each task wrong, what would it cost? (Example: a wrong report wastes an hour; a wrong price email can lose a job) 5. Which systems already run, and what one number should each move? (Example: lead follow-up, booked calls) Rules: - Grade each task low, medium or high by the output it creates for other people, not by hours spent. - Third-Time Rule: first time, do it by hand and take notes. Second time, write a checklist plus one example of a good result. Third time, build it: the checklist is its job spec, the example is its test. - What a wrong output costs sets the trust level. Frequent and cheap: it runs alone and I check samples. Frequent and costly: it drafts and a person approves. Rare and cheap: checklist only. Rare and costly: by hand. - One build per week. Test it on past data before it touches a customer. - Design time first in the week, maintenance on its own day, a Friday check on one number. - Never invent hours, counts or costs. Ask me. Answer in this format: Week grade: [hours at low, medium, high] Build this week: [one task, why, its test] Write a checklist for: [tasks on their second time] Keep by hand: [tasks, and why] Week plan: [Monday to Friday, one line each] Friday number: [the metric and how to check it] Next three actions: 1. 2. 3.
What to do this week
1. Grade last week's calendar low, medium or high. Name one low block to cut.
2. Count how many times each task has come up. Pick one on its third time, and write its checklist and its test.
3. Put design time on Monday morning and maintenance on Thursday. Protect both.
Back to the two marketers. Same pile on Monday. Next Monday, only one of them has a smaller pile.
Ready to practice this on a real company? Start with how to become a marketing engineer in 30 days, or see how we train marketing engineers.
Doing the work by hand fills this week. Building the system clears the next fifty weeks.
Filip Kovacevic is the founder of Anar Agency in Phoenix. He spent five years running SEO, Meta ads, email, and content for medical practices across the United States, and now does the same work for healthcare, home-service, legal, and professional-service businesses, alongside AI implementation. More from Filip →
Want to work this week on real systems?
We train marketers on the systems we run for clients, one working system at a time, and the people who do the best work build with us.
See the training →Hiring instead? See how we build the first system for you.