The First 90 Days With a Marketing Engineer: One System, Not Five

Day 61 is where weak first quarters go quiet

It is day 61. Your new marketing engineer has five demos, three new tools on the company card, and a screen recording for each one. Nobody on the team uses any of them.

That is the shape a bad first quarter takes. It is rarely a talent problem. It is a scope problem.

A marketing engineer builds systems: agents, data and automations that keep working after the builder stops touching them. The first 90 days decide whether you end up with one of those or with a folder of experiments.

Most companies are not good at first months for any hire. Gallup found that only 12% of employees strongly agree their organization does a great job onboarding new people.

A new kind of role makes that harder, because nobody in the building has done this job before. So the plan has to come from you, and it has to fit on one page.

One system. Ninety days. Three proofs.

We call it the Three Proofs. By day 30 the engineer proves the problem: one number, measured, with a baseline. By day 60 they prove the output: one system live on real data, with a person approving what it makes.

By day 90 they prove independence. The system runs for a week without them, and the number has moved or you know why it has not.

Before day one: four things only you can hand over

The first week of this hire is usually lost to waiting for logins. Four things have to be ready before the start date, and only the owner can give them.

One number. Pick the business number this person should move by day 90: demo requests from the right accounts, cost per booked call, replies from qualified accounts, or hours your team spends on reporting. If you cannot name it, you are not ready to hire, and it is cheaper to learn that now.

Read access. The CRM, the ad accounts, analytics, call recordings and support tickets. Read-only at first; write access comes once a system has shown it behaves.

One approver. A named person who reads what the system makes before it reaches a customer, and who has 20 minutes a day for it. Without one, every output waits for a meeting.

Twenty real conversations. Sales calls, lost-deal notes, support threads. They are the raw material for the whole first month, and they are the thing most companies take longest to dig up.

Days 1 to 30: read everything, build nothing big, sign one memo

The first month is mostly reading. Profound, the company that named the role, offers hirers a sample job description that starts the engineer by shadowing every marketing function and finding what can be automated, with people kept only at the decision points.

In practice that means sitting in on sales calls, reading tickets, and watching how the weekly report actually gets made late on a Thursday. The engineer is looking for work your team repeats every week, and for the step where a lead or a reply goes cold.

By day 10 you should see a stack map: every tool, who logs in, what data moves between them, and what each one costs a month. By day 20, a memo of what customers are saying, with a quote or a link behind every claim.

Greg Isenberg sets up the same first week in his episode on the role: audit one real company and come out with a map of the customer, the pain, the words buyers use, and the first thing to test. The tools matter less than the order.

The month ends with one page. We call it the decision memo: which system gets built, which number it moves, what that number is today, who approves, and what it will cost to run each month.

That baseline matters more than anything built in month one. Without it, day 90 turns into an argument about feelings.

If you want the questions the audit should answer, our marketing engineering audit lists 20 of them, sorted by system. The place to keep what the engineer learns, so it does not live in one person's head, is the growth repo.

One small, visible win in the first three weeks is allowed, and often smart. An alert when a new lead has waited too long is a small build, it shows the team the engineer ships, and the case for it is in speed to lead.

Small wins are allowed. Second systems are not.

Days 31 to 60: one system, live on real data, with a person approving

Month two is the build, and the rule is to start smaller than feels useful. Anthropic's guidance for teams building agents, Building Effective Agents, says to find the simplest solution that works and add complexity only when it is needed, which can mean no agent at all.

Before anything gets built, the engineer writes a job spec for the system the way you would write one for a person: what it reads, when it runs, what it filters out, what good output looks like, what needs approval, and the number it answers to. Our template is in how to write a job spec for an AI agent.

The first version should run on real data by about day 45. Every output goes to the approver before it reaches a customer, and every correction gets written down as a rule the system reads on its next run.

Isenberg describes this as training an agent the way you would train a new hire. Small tasks first, watch the work, fix the mistakes, then widen the scope as trust grows.

That is why month two looks slow from the outside. The visible output is small on purpose, because the real work is the list of rules growing underneath it.

Quality needs its own test. A system that gets a task right once has proved very little, and how to evaluate AI agents covers running the same task many times against a set of known answers.

What you should see at day 60: the system ran every scheduled time for two weeks, the approver is editing less of what it makes, and the number sits next to its baseline. It is too early to call the result. It is not too early to see whether the thing runs.

Days 61 to 90: make it run without the person who built it

A system the builder has to babysit is still a project. The last month exists to turn it into something your team owns.

Profound's sample job description sets the bar: a system is not done until the team has adopted it, it handles edge cases, and it sounds like your company. Its posting for a Forward Deployed Marketing Engineer goes further, saying that shipping the build does not finish the job and making the hire accountable for adoption.

Three things happen in this month. First, the engineer writes the handover: what the system does, where it runs, what it costs, what breaks it, and how to switch it off.

Second, the engineer steps away from it for a full week and someone else runs it. Software teams have a blunt name for the risk this tests, the bus factor: how many people would have to vanish before a project stalls.

A bus factor of one is a person, not a system. It also fails the Next-Tuesday Test from our pillar article, which asks whether something still works next week without the person who made it.

Third, the number gets read against the baseline in the Monday memo, and you make one of three calls.

Keep it and pick the second system. Fix it, with a dated deadline. Or kill it and write down why.

Figma's posting for a Marketing Engineer, AI Deployment measures success three ways: agents live, hours saved, revenue driven. It also asks the engineer to retire the agents that do not drive results, which is the call most teams avoid making.

Clay describes its GTM engineers, the sales-side cousin of this role, the same way: success measured by meetings booked, hours saved and conversion lifted. Not by how many workflows exist.

Assured's AI Marketing Engineer posting makes the hire accountable above all for whether the system is on. Put that sentence in your own offer letter.

The one-system rule: five half-built systems add up to zero

Every owner wants all six systems. The postings, the critics and the failure data all point the other way.

MIT's study of enterprise AI, as Fortune reported it, found about 5% of pilots reaching rapid revenue growth, and the lead researcher said the winners pick one pain point and execute well. Gartner predicts more than 40% of agentic AI projects will be canceled by the end of 2027, over cost, unclear value or weak risk controls.

Neither number is about marketing engineers. Both describe what happens when a company starts many experiments and finishes none.

So the first system gets chosen by the number, not by what looks best in a demo. The figure below maps the six systems to the number each one moves; pick the row that matches the number you named before day one.

Our rule is the one we hold ourselves to: one system, measured against a number the business already tracks, before the next one starts. If a second system starts before day 90, ask what is wrong with the first.

Red flags by day 30, 60 and 90

A hire that is going wrong usually shows it early, if you know where to look. The checklist below is the one we would use on our own team.

By day 30: no named number, no baseline, a new tool bought before the conversations were read, or a stack map nobody else has seen. Any of these means the reading month was skipped.

By day 60: a system that runs only when the engineer runs it, output reaching customers without approval, or an answer about monthly cost that starts with "it depends."

By day 90: no handover document, a number that was never read against its baseline, or a plan for systems two through five before system one has a verdict.

One flag is a conversation. Three is a decision.

If the flags stack up, check the fit before you blame the person. Hanna Huffman, writing in Marketer in the Loop, separates the engineer who serves a team of marketers from the solo operator who runs the whole function, and warns that hiring one when you needed the other is costly and hard to undo.

"We need results in month one, not a plan"

Fair. You are paying a salary or a retainer, and 90 days is a long time to wait for a number.

Here is the honest answer. Month one can produce a visible win, like the lead alert above, and a memo that tells you something about your customers you did not know. It cannot produce a proven system, because pipeline does not move that fast and a result read after two weeks is mostly noise.

Isenberg describes consultants doing this work in embeds of 30, 60 or 90 days that build one growth system and sell the outcome. That length is not padding. It is roughly how long one honest read of one number takes.

There are also times you should not start the clock at all. If you cannot give read access to the CRM and the call recordings, if nobody has 20 minutes a day to approve output, or if you cannot name the number, wait; the hire will spend the quarter waiting with you.

And if the real question is whether to hire anyone, our math on consultants versus an in-house team puts the costs side by side.

How we run the first 90 days

We run our marketing engineering engagements on the same clock. An audit in weeks one and two, one system built in weeks three to eight, then we hand it over or keep running it, and the next system does not start until the first has been measured.

We hold our own systems to it too. This library is built by code, and nothing publishes until scripts confirm that every source link loads, no paragraph runs past three sentences, and no sentence is lifted from a source.

Our customer-language agent reads 121 practitioner accounts on X for a topic, with a hard cap of $0.50 a run; a typical run costs about $0.02. Each of these systems has a job spec, a cost line and an off switch, which is what day 90 should hand you.

If you would rather have the system than the hire, marketing engineer as a service explains how that arrangement works and what you keep at the end. The routing, alerts and handoffs underneath most of these systems are what our AI automation work covers.

What to read next, and why

How to Evaluate a Marketing Engineer's Work [scorecard]. The weekly card you read at day 30, 60 and 90. Without it, this plan has no way to say whether it worked.

The Growth Cockpit [system]. The Monday memo where the day-90 number gets read. Often the best second system, because it makes every later one easier to judge.

Hire a Marketing Engineer, an Agency, or a Consultant? [decision]. Read it before you post the job. The 90-day plan is the same; the cost of a wrong pick is not.

What a Marketing Engineer Does All Day [explainer]. What the week looks like after day 90, once the first system runs and the second is on the board.

So the simple takeaway is this: give a new marketing engineer one number and one system, and judge the quarter on whether it still runs on day 91 without them.