The First 90 Days as a Martech Leader: Audit Before You Buy, Consolidate or Rebuild
New martech leaders should not begin by buying tools or ripping out platforms. The first 90 days should create a trusted baseline of capability, ownership, overlap and risk.
The first 90 days in a martech leadership role are dangerous because everyone wants you to be decisive before you are properly informed.
The CMO wants momentum. Finance wants savings. Sales wants cleaner handoffs. The digital team wants faster campaigns. The agency wants fewer approval layers. Someone from IT wants to know why marketing has seven tools that all appear to “manage audiences”. And at least one person will quietly suggest replacing the marketing automation platform because they personally hate the interface.
Maybe they are right. Maybe they just had a bad Tuesday in 2021 and never recovered.
Either way, your first job is not to buy, consolidate or rebuild. Your first job is to understand the operating reality. The inherited martech stack is not just technology. It is a fossil record of past strategies, vendor promises, budget compromises, integrations, political deals, agency preferences, skill gaps and workarounds that became permanent because no one had the time to fix them.
A good first 90 days turns that mess into a decision-ready picture.
Key Takeaways
| Takeaway | What it means in practice |
|---|---|
| Do not start with a tool decision | Buying, cutting or rebuilding before diagnosis often creates new duplication or breaks hidden dependencies. |
| Build a stack baseline by day 90 | Your first 90 days should produce a trusted view of tools, owners, capabilities, usage, overlap, renewals and risk. |
| Use 30-60-90 sequencing | Month one should map reality, month two should audit capability and governance, and month three should turn findings into decisions. |
| Treat overlap as an operating issue | Capability duplication is not just a cost problem; it affects ownership, data trust, workflow speed and stakeholder confidence. |
| Make the first roadmap evidence-based | The strongest day-90 plan separates stabilise, optimise and re-architect work rather than pretending every issue is transformation. |
Short answer: what should a new martech leader do in the first 90 days?
A new martech or marketing operations leader should spend the first 90 days building a reliable baseline of the inherited stack before making major technology decisions. In the first 30 days, they should listen, map stakeholders, collect tool and renewal data, and protect what already works. In days 31–60, they should audit capabilities, usage, ownership, overlap, integrations and governance. In days 61–90, they should prioritise quick wins, renewal actions, risk fixes and a roadmap for stabilising, optimising or re-architecting the stack.
Why the first 90 days matter in martech leadership
Marketing technology is now too large, too expensive and too interdependent for leaders to treat the stack as a side issue. The 2025 Marketing Technology Landscape lists 15,384 martech solutions and describes 100x growth since 2011.1 Gartner’s public martech guidance says marketing technology accounts for nearly 22% of total marketing spend, while its 2025 survey found martech utilisation at 49% and only 15% of organisations meeting the standard of high performers with strong strategic and ROI outcomes.2
That creates a brutal leadership problem. The stack is commercially important, operationally messy and rarely understood by one person.
The new martech leader inherits all of it.
Most first-90-days advice is too generic for this reality. It tells you to listen, build relationships, create quick wins and develop a roadmap. Fine. Useful. But in martech, those ideas need a more specific operating model. You are not only joining a team. You are taking responsibility for a live ecosystem of tools, data, vendors, licences, workflows, automations and dashboards that other people already depend on.
This is why your first 90 days should produce a stack baseline: a trusted view of what exists, what it does, who owns it, where capabilities overlap, what is underused, what is risky and which decisions are time-sensitive.
Without that baseline, “strategy” becomes theatre.
The two wrong first moves
New leaders usually make one of two mistakes.
The first mistake is tool-first decisiveness. This is where you arrive, see a messy environment and immediately start pushing for a new platform, a consolidation project or a shiny AI layer because it will signal change. It feels bold. It looks like leadership. It is often just procurement with better shoes.
The second mistake is analysis paralysis. This is where you keep interviewing, documenting and mapping until the organisation stops believing anything will change. You become the person who is always “building the view”. The view gets larger. The stack remains haunted.
The better path is diagnosis with cadence. You do not need perfect knowledge before acting. You need enough structured knowledge to make the first set of decisions without damaging the system.
| Bad first move | Why it fails | Better alternative |
|---|---|---|
| Buy a new platform before diagnosis | You may duplicate capability you already own or create another adoption burden | Audit capabilities, usage and gaps before procurement starts |
| Cut tools to show savings | You may remove a hidden dependency and create manual work elsewhere | Score tools by usage, overlap, dependency, cost and risk |
| Rebuild governance immediately | You may create process that ignores how work actually gets done | Observe workflows before redesigning controls |
| Chase executive pet problems | You may optimise for the loudest stakeholder rather than the highest-value issue | Build a transparent prioritisation model |
| Stay in discovery too long | Stakeholders lose confidence and the old operating model hardens | Deliver early findings and quick operational fixes |
The trick is not to avoid action. The trick is to avoid performative action.
The 30-60-90 day plan for a new martech leader
A useful first-90-days plan should match the rhythm of learning, diagnosis and decision-making. The work should get more specific over time.
| Period | Primary job | Core outputs |
|---|---|---|
| Days 1–30 | Understand the inherited reality | Stakeholder map, known stack inventory, renewal calendar, pain-point register and first-pass capability map |
| Days 31–60 | Audit capability, overlap and governance | Usage assessment, ownership map, overlap analysis, integration risk view and governance fixes |
| Days 61–90 | Prioritise and build the roadmap | Quick wins, renewal actions, risk register, decision principles and stabilise/optimise/re-architect roadmap |
Days 1–30: Listen, map and protect what works
Your first month should be about understanding. Not passively. Not with a notebook and a vague commitment to “circle back”. You are building a structured picture of the stack and the operating model around it.
MarketingOps.com recommends that new marketing operations hires use the first 30 days to gather information from go-to-market leaders, end users and operations staff, then move into system audit and recommendation phases.3 Etumos gives similar advice for marketing operations leaders, recommending that the first month focus on the team, stakeholders and the martech stack before moving into deeper process and governance work.4
The work in the first month is to establish what is true enough to act on.
The conversations to have
You need to speak with executive stakeholders, channel owners, lifecycle and campaign teams, sales or revenue operations, data and analytics, IT, legal or compliance, finance, procurement and agency partners. The goal is not to ask everyone for a wish list. The goal is to understand the gap between how the stack is described and how the work actually happens.
| Stakeholder | Questions worth asking |
|---|---|
| CMO / executive sponsor | What outcomes must the stack support this year? Where does leadership believe the stack is underperforming? What decisions are already politically sensitive? |
| Marketing operations team | Which tools are stable, fragile, underused or painful? Where is the team stuck in reactive support? What breaks most often? |
| Channel owners | Which platforms help you move quickly? Which ones slow you down? Where do you use manual workarounds? |
| Sales / RevOps | Where do lead flow, attribution, routing or CRM handoffs fail? What marketing data is not trusted? |
| Data / analytics | Which data sources are trusted? Which dashboards are argued over? Where does duplication create conflicting numbers? |
| IT / security | Which integrations or permissions create risk? Which tools are outside formal governance? |
| Finance / procurement | Which renewals are coming up? Where is spend scrutiny highest? Which contracts are hard to exit? |
Two things usually surface quickly. First, the stack will be more fragmented than the official inventory suggests. Second, the most painful issues are often not caused by the worst tools. They are caused by unclear ownership, broken workflows, integration debt or tools being used for jobs they were never designed to do.
That is why you need a capability view.
The first-month deliverables
By the end of the first 30 days, you should have a working stack inventory, a stakeholder map, a renewal calendar, a list of known pain points and a first-pass capability map. None of this needs to be perfect. It needs to be credible enough that people recognise their reality in it.
| Deliverable | What it should contain | Why it matters |
|---|---|---|
| Known stack inventory | Tools, owners, categories, users, contracts and business units | Establishes the visible baseline |
| Stakeholder map | Decision-makers, admins, power users, blockers and hidden owners | Shows where influence and dependency sit |
| Renewal calendar | Upcoming renewal dates, costs and exit windows | Connects discovery to commercial urgency |
| Pain-point register | Repeated issues from interviews, grouped by capability | Prevents anecdotal noise from dominating |
| Capability map | The jobs the stack must perform and which tools support them | Reveals overlap, gaps and ambiguity |
The first month is also when you protect what already works. New leaders sometimes assume inherited systems are broken because the environment looks messy. That is arrogant and risky. Some of the mess may be necessary because the organisation has real complexity. Some old workflows may be ugly but reliable. Some unloved platforms may be doing important work quietly.
Do not break the boring thing that works because it offends your architectural taste.
Days 31–60: Audit capabilities, overlap and governance
The second month is where discovery becomes diagnosis. You have the first-pass inventory. Now you need to test it.
This is the right moment for a structured martech stack audit. Not a vendor list. A capability, usage, ownership and risk audit. Gartner’s public guidance recommends periodic martech audits that document vendors and products, engage stakeholders, map organisational impact, assess cost and utilisation, analyse gaps, visualise the ecosystem and repeat the process over time.2 That sequence is useful because it treats the stack as a living system rather than a static asset register.
Your audit should answer five questions.
| Audit question | What you are looking for |
|---|---|
| What capabilities does the business need from the stack? | The actual jobs to be done, not vendor category labels |
| Which tools support each capability? | Overlap, gaps and accidental dependency |
| How deeply is each tool used? | Adoption, feature utilisation and shelfware risk |
| Where does data move? | Integration health, reporting trust and failure points |
| Which decisions are commercially time-sensitive? | Renewals, contract constraints and budget pressure |
This is where you discover whether the stack is truly overbuilt or just poorly understood. Sometimes the problem is duplication. Sometimes it is fragmentation. Sometimes it is that a capable platform was bought, configured badly, handed to an undertrained team and then blamed for being “not strategic”.
Tools get blamed for organisational failure all the time. They sit there with a dashboard and a renewal date, catching strays.
Audit overlap without starting a turf war
Overlap is politically sensitive because tools become part of team identity. The lifecycle team may prefer one journey builder. The digital team may trust a different analytics platform. Sales may insist the CRM report is the only source of truth, which is convenient because it is also the one that makes them look least culpable.
Do not frame overlap as “who is wasting money?” Frame it as “where do we have duplicated capability, conflicting data or avoidable complexity?” That shift matters.
| Overlap type | What it looks like | How to handle it |
|---|---|---|
| Healthy redundancy | Two tools perform similar jobs for genuinely different use cases | Document the rationale and governance |
| Capability duplication | Multiple tools perform the same job for the same team or audience | Decide which tool should become primary |
| Data duplication | Multiple systems hold similar data with inconsistent definitions | Establish source-of-truth rules |
| Workflow duplication | Teams recreate the same process in different tools | Standardise process or clarify exceptions |
| Commercial duplication | Paid capabilities exist in one platform while another tool is bought for the same function | Review renewal and consolidation options |
The aim is not to remove every overlap. The aim is to make overlap intentional.
Fix governance where it is blocking execution
Month two is also when governance becomes visible. Permissions, naming conventions, data standards, approval flows, campaign QA, integration ownership and documentation all need attention. Etumos recommends focusing on governance, permissions, process, naming conventions and documentation in the second month of a new marketing operations role.4
Do not attempt to build a grand governance cathedral. People will ignore it, and they will be right to. Start with the controls that reduce risk or speed up execution.
A practical governance review should identify where teams need clearer standards, where approvals are slowing harmless work, where uncontrolled access is risky, where documentation is absent and where naming or taxonomy issues are damaging reporting.
Governance is not the goal. Better work is the goal.
Days 61–90: Prioritise, secure quick wins and build the roadmap
The third month is when you move from diagnosis to direction. You should now have enough evidence to make recommendations. Not all recommendations. The first set.
Your job is to distinguish urgent from important, visible from valuable, and politically loud from operationally material.
| Decision area | What to decide by day 90 |
|---|---|
| Quick wins | Which fixes can reduce pain or risk without major platform change? |
| Renewal actions | Which upcoming renewals require retain, renegotiate, consolidate or retire decisions? |
| Capability gaps | Which missing capabilities are genuinely blocking strategy? |
| Overlap decisions | Which duplicated capabilities need consolidation or clearer ownership? |
| Governance fixes | Which standards, roles or processes need immediate correction? |
| Roadmap | Which initiatives belong in the next quarter, half-year and annual planning cycle? |
This is also the moment to show restraint. Not every pain point deserves a project. Not every tool complaint deserves replacement. Not every executive concern deserves a transformation programme with a logo.
A strong day-90 roadmap should include three horizons.
| Horizon | Timeframe | Focus |
|---|---|---|
| Stabilise | Next 30–60 days | Fix obvious operational pain, documentation gaps, ownership issues and renewal risks |
| Optimise | Next quarter | Improve utilisation, governance, integrations, reporting trust and workflow consistency |
| Re-architect | Next 6–12 months | Evaluate major consolidation, platform replacement or capability investments only where evidence supports it |
This staged approach helps you earn trust. You show that you can improve the current system without pretending it is perfect, and you can recommend bigger change without sounding like you arrived with a vendor deck already open.
The day-90 artefacts that matter
By the end of your first 90 days, you should be able to put a small number of useful artefacts in front of leadership. These should not be decorative. They should help the organisation make decisions.
| Artefact | Purpose |
|---|---|
| Stack baseline | Shows the current tools, owners, capabilities, usage, integrations and risks |
| Capability overlap map | Identifies duplicated, underused or unclear capabilities across the stack |
| Renewal decision calendar | Connects audit findings to commercial timing and negotiation windows |
| Top risks register | Captures operational, data, compliance, vendor and ownership risks |
| Prioritised roadmap | Shows what will be stabilised, optimised or re-architected and when |
| Decision principles | Defines how the organisation will evaluate future tool decisions |
The decision principles are more important than they sound. Without them, the organisation returns to tool-by-tool argument. With them, you can create a more disciplined conversation.
| Principle | Practical meaning |
|---|---|
| Capabilities before vendors | We define the job before evaluating the tool |
| Adoption before acquisition | We improve use of existing capability before buying duplicate capability |
| Evidence before opinion | We use usage, cost, risk and dependency data to make decisions |
| Governance before scale | We do not automate broken processes faster |
| Renewals before surprises | We make decisions early enough to avoid forced renewals |
These principles will annoy someone. Good. That is often how you know they are useful.
Common first-90-days questions for martech leaders
Should a new martech leader buy tools in the first 90 days?
Usually, no. The first 90 days should focus on diagnosis unless there is a critical risk, failed platform or urgent compliance issue. Buying before mapping the stack can duplicate existing capability, create new integration debt and weaken stakeholder trust.
What is the most important first-90-days deliverable?
The most important deliverable is a trusted stack baseline. It should show tools, capabilities, owners, usage, integrations, renewals, risks and overlap. Without this baseline, roadmap and investment decisions rely too heavily on anecdotes and politics.
How quickly should a new martech leader make changes?
A new leader should make small operational fixes quickly where the evidence is clear, but should avoid major buying, consolidation or rebuild decisions until they understand dependencies. The best first 90 days combines visible progress with disciplined diagnosis.
What should be included in a martech 30-60-90 day plan?
A martech 30-60-90 day plan should include stakeholder discovery, stack inventory, renewal calendar, capability mapping, usage and overlap assessment, governance review, quick wins, risk register and a roadmap for stabilising, optimising and re-architecting the stack.
Where StackOverlap fits in the first 90 days
StackOverlap is useful in the first 90 days because it gives a new martech leader a safer way to build the baseline. It helps move the conversation away from vendor loyalty and towards capability overlap, usage reality and decision-making.
The initial StackOverlap audit can show where tools appear to collide, where categories are crowded, and where the stack may contain duplicated functionality. As the product evolves into ongoing SaaS management, the value becomes more powerful: monthly check-ins, monitoring feeds, renewal tracking, budget views and feedback-powered recommendations can turn the first-90-days baseline into a living management system.
That matters because the first 90 days should not produce a beautiful static report. It should produce a management rhythm.
The stack will keep changing. New AI features will appear inside tools you already own. Vendors will reposition. Budgets will move. Agencies will bring preferred platforms. Teams will build workarounds. The question is not whether the stack will drift. It will. The question is whether you notice early enough to do something useful.
The blunt version
If you are a new martech leader, do not start by buying a tool. Do not start by ripping out a tool. Do not start by announcing a transformation programme that requires twelve steering committees and a mural of hexagons.
Start by finding out what is true.
Map the stack. Map the capabilities. Map the owners. Map the overlaps. Map the renewals. Map the risks. Then make the first set of decisions with evidence.
That is leadership. Everything else is just a louder way to make the old mess more expensive.
Template placeholder: Download the Martech Leader 30-60-90 Audit Plan and use it to build a decision-ready view of your inherited stack before recommending new spend.
References
- Chiefmartec, “2025 Marketing Technology Landscape Supergraphic: 100X growth since 2011, but now with AI…”, 2025. https://chiefmartec.com/2025/05/2025-marketing-technology-landscape-supergraphic-100x-growth-since-2011-but-now-with-ai/ ↩
- Gartner, “Maximize ROI With Marketing Technology (Martech)”, accessed 2026. https://www.gartner.com/en/marketing/topics/marketing-technology ↩↩
- MarketingOps.com, “The New Marketing Operations Hire 30-60-90 Day Plan”, 2022. https://marketingops.com/the-new-marketing-operations-hire-30-60-90-day-plan/ ↩
- Etumos, “ProTips for Your First 90 Days in a New Marketing Operations Role”, 2024. https://etumos.com/marketing-productivity/protips-for-your-first-90-days-in-a-new-marketing-operations-role/ ↩↩