The Martech (Marketing Technology) team at Ramp is part of a broader Systems team, which also includes Business Technology. This broader team manages 30 tools and a $10M budget. The Martech team's structure and responsibilities are clarified further in this doc. In other companies, it is common for marketing technology to live in the product org as a technical product management function.

The goal of this doc is to take a step back and reset expectations on who is doing what, what are my expectations of the team, and what are their expectations of me. Creating this doc happened over a month and a half. I started with a conversation with the team where I said, "I'm struggling and feel overwhelmed." It became clear that people on my team didn't know what we need from each other.

One of the big challenges with this team is that it formed from a reorg. I didn't hire these people, I just adopted them. When you adopt someone versus hiring fresh, there's not always the right moment in time to have that rethink. After working together in 6 months, we needed a reset.

The conversation uncovered that there was a lot of ambiguity in who owns what. Part of this doc divides up Marketing Technology and Operations into distinct domains so we could slice out who owns which domain, what are the skills within those domains, what are the roles and responsibilities in those domains, and how do we align those back to the stakeholders we serve. There were all these people asking for stuff from us, and all these things we had to do, and we really needed to find alignment between them.

The overall framework of this document is first setting expectations with the team to create alignment, then dividing the team into who does what, then figuring out what ownership looks like in the different domains. The only flaw with this framework is that with a team of 4 or 5, there's not a lot of juice to squeeze out and people have to own multiple things with some overlap. This structure would be better for a team of 15 to 20.

Since we deployed these expectations in December, there hasn't been a moment when people haven't been meeting them. Our next step is to implement a leveling framework and people who are exceeding expectations will move up.

The Marketing Ops team was originally hired by a VP who was creating a broader Business Operations function. When I first joined Ramp, Business Operations included Product Operations, Marketing Operations, Go to Market Operations...all of these operations pods. They were all rolling up into a person who not only didn't have the bandwidth to stretch themselves across all these areas, but also didn't have the deep technical capacity to provide leadership and stewardship to the team leads. This person is brilliant, but she's not a technologist and didn't have ten years of experience building technical systems, so having that person in charge of systems didn't make a lot of sense.

What we realized over time is actually the operational functions need to live really closely with the technological functions. For instance, if you have Business Technology, that team will be the final decision maker on our tools and technology. Changes to those systems should not be made without that team being the final decider. What was happening was that we had these operations functions that were touching and making changes to systems without being in sync with the actual leaders of the technology function themselves.

I drove this change at Ramp because it made a lot more sense to have our operations and tech together. I just don't really believe that the people administering tools should live separately from the people who are ultimately responsible and accountable to the stakeholders for managing those tools and making sure they work the way they're expected. We don't want situations where you're both admins of the tool, you're both making changes, and you can disagree. Who is the final decision maker?

This happens a lot to leaders where they find themselves in a role where they didn't hire the people they now have to manage. It's a different story when you're hiring someone fresh because you have this moment in time where you just set expectations. When you adopt somebody, especially if it's over a long period of time where you've been working with them, first as a third party, and then as a manager, there's not always the right moment in time to have that conversation. I developed this doc largely to go through that exercise of "Okay, you've been under the Systems team and me for six months now. Nobody has gone to lengths to reset expectations with you. Let's just do it. Let's understand what I need from you to be successful and what you need from me to be successful."

When I hire someone, I usually share with them my operating manual, where it describes exactly who I am, what I care about, what my preferences are, and what I expect of people on my team.

I did fear that this conversation wouldn't be received well, but I started these conversations with the hard truth, which was things aren't working the way they are today. I asked the team to tell me how they felt, but that if I didn't hear anything, I would assume they agreed. What it came down to was the team just wasn't operating efficiently. I was the blocker for so many things, and it just didn't feel like it was working. It was just this human moment where I was like: "This is really hard and when you don't have anyone to rely on, it can be brutal." I think that allowed us to have a really honest conversation.

It had to be a two-way street, though. I want to be able to tell you what my expectations are, but I'm also inviting you to tell me what you need from me, and that's the key unlock. If you just tell people what you demand of them with no opportunity for them to participate, of course they're going to have feelings about that. But if you say, "Hey, this is how I'm feeling, this is what I think I need, and this is what I expect as your leader," and then you ask what they need from you, that makes it clear that this is a relationship that goes both ways.

This is the essence of servant leadership: you work for those who work for you. That means allowing people to participate in this process. And maybe they didn't tell me how they feel and they're actually really anxious and angry, but overall I didn't get an emotional response from anybody. Instead, their response was, "I feel really sorry you feel this way. I definitely want to step up and do more."

The unlock for me, though, was they didn't express this in terms of expectation. They were like, "We want to do more, but often we don't know whether you're going to do something or we're going to do it. You're the funnel. If you want to give us more work, then how do we make it easier for us to take work without having to come talk to you?" And I was like, "Yeah, that's a great point."

What was going on in the background is that not everyone on the team was meeting my expectations for what I needed. But I also had never really communicated what I needed.

My default assumption with almost all employees is that if someone's not performing, it's usually not their fault. It's usually management's fault. That may be a controversial opinion, but I think usually that's what the answer is.

I believe in scaling people; if you want to build a big, awesome company, you need to invest in your people. You can't just write them off. People need time and a chance to grow.

In highly technical and specific fields, there's always an expectation that you're a player-coach. Successful Engineering Managers have deep technical expertise and can lend that experience to people who are solving problems. Martech at its essence is more of an engineering role than a business role. It's not easy for me to extract myself as a player. Sometimes the only way to do something right is to jump in and show people how it's done. And especially since Martech finds itself in roles where they're working cross-functionally with different teams that have both technical and non-technical stakeholders, there's just a lot of opportunity for things to go wrong.

I tend to be a hands-on manager, and I think a lot of Millennial and Gen Z workers respect and admire people who are player-coaches. My point of view is that I'm going to be a more successful manager and operator if I do some operating sometimes.

However, over time, the amount of time and frequency that you operate and the extent to which you need to jump in goes down. That's what's happening on the team as people grow and learn what great looks like. People will copy you if you're clear about what great looks like. I've found a lot of success in modeling behavior and outputs that are world class. You lose the capacity to set the standard for great if you aren't doing it frequently, so I always like to have some skin in the game. It also helps me understand when someone is truly next level.

I included this section because we had a new CMO join in December who talks a lot in these terms. I think it's really powerful to align your cultural norms to that of the team and the leader that just joined. There had been a lot of turnover on the Marketing team at the leadership level, so I think it's important to describe what we stand for and to repeat it back to people. This is who we are. These are our values. These are the things we care about. This stuff can seem kind of hand-wavy, but if you don't do it, it's way worse because then people can point to the blank spot and say "we don't even know what we stand for."

I had created this mission statement back in June when I joined. Even though I was not managing MarOps at the time, I thought it was very important for the Systems team to have a mission statement. It's something we don't think about very often but when we do it's very powerful.

Having a mission statement that everyone feels bought into and can contribute towards is really important, but you have to start somewhere. This is maybe the second or third iteration, and it started with me putting something on paper what MarOps and Martech should do and then getting feedback on it. Inviting people into the process was key. Creating leadership can sometimes just be as small as getting feedback from the people that you serve.

Inviting people into the process with all of these things is the biggest piece of advice. You're not weaker for inviting people in.

We have a lot of tools, including different tools for different teams. With systems work, this can lead to big problems. When I first joined, there was an over-tendency to ping people in private messages on Slack asking for things. There are so many problems with this: it's not cross functional, it's not tracked, you're creating work for yourself.

This process section was to clearly define the best practices. We needed to state exactly how we work so we can point people to this. This is included in our onboarding deck that I give to every new hire. When people come and ask for something in the wrong way, we don't feel bad asking them to do it the right way because I know they have seen my expectations for how they operate. We have something we can refer back to.

Part of our challenges as a team were actually due to how I had initially set up our Asana board. When the MarOps and MarTech teams originally merged, I forced all of our tickets to go through the same funnel and I auto-assigned myself to all tickets as a forcing function to create alignment. What was happening before was that we had two boards with everyone managing their own tickets. In the beginning, I needed to force myself into the situation to control it and help allocate people's time properly. It forced us to get on the same page and talk about what we're working on each week. Then as a team, we were able to think about us together solving problems, as opposed to each of us solving problems on our own.

Initially this was a great idea. The sprint planning process worked beautifully. But then six months later, sprint planning was taking an hour. At that point, we had a functioning team. We had alignment. We all had context. We all had good faith in one another and now I'm the bottleneck. All the work coming through me was actually slowing things down. That's why the expectations conversation led to the Domains section later in this doc. We divided MarOps, MarTech, and Marketing Analytics because once we had established a basis for doing work, had a sprint process, and were meeting regularly, then we had the foundation for teams to be managing their own time.

In a fully evolved team, we wouldn't have multiple people in either of the columns. The reason why there's a lot of side-by-side ownership is because we're small and scrappy. Over time, these would be aligned to discrete people, but this is the framework for that. I can see how to build Person X into the owner of MarOps.

"All" are things in a Slack channel. When in doubt, I'm ultimately accountable and delegate to the right person.

Austin Hay

I created this document to articulate expectations, ownership, and processes for a complex team that formed from a reorg.

 Expectations, Operating Norms & How We Organize

When Martech came together in July of last year, 

We had been working together, but I didn’t formally hire X or Y and so we never did a proper manager introduction.

Usually when I have staffed teams, I like to do a round of expectation setting whereby I clarify my role, and my expectations, and the expectations that others have of me.

it's led me to ask a number of questions:

Are people bored/not having enough to do?

What do people think we should be working on that we are not working on?

What are we working on that isn’t clear “why”?

Am I helping people uplevel the way they want? What do we need to change to make it happen?

Am I helping people achieve what they want in their careers?

So with that, I wanted to reopen and re explore my expectations of this team and codify the expectations that my team has of me.

I would love for the team to collaborate and communicate their expectations of me, that way I can be a positive contributor to our work and your growth.

When a task is delegated, it’s important that it gets done

 and that I don’t have to follow up or micromanage the outcome.

I expect that DRs will ask for help quickly if they need it.

I expect my DRs to come to me and not be fearful of asking for help.

I expect that the owner of a project or priority is sufficiently communicating updates

If I have to ask what is happening with X, it means the communication flow is not adequate.

I expect my DRs to share qualitative and quantitative data about their workload

. I operate on the principle “no news means things are good” so I need feedback/input to know when people are overwhelmed.

I expect my team to be extremely proactive

. I don’t have many pet peeves, but one of them is feeling like I have to chase people. I don’t like to micromanage, so I expect my team to share information on a frequency that creates confidence in their ability to get stuff done.

I expect my team to treat me as a coach and a player

 Sometimes deferring specific tasks to me that they believe I should do (or that I must do), and proactively asking for help, advice, tactics etc. in order to deliver on results, grow in their careers, and thrive here at Ramp.

I should be expected to make time on my schedule to meet the needs of my team.

I should be expected to provide extreme visibility into my interactions with other leaders. This should be done proactively, but also upon request.

I should be expected to set the strategic roadmap for our team with input from everyone, and be willing and able to backup my thinking when probed.

I should be expected to hear people’s feedback and adjust projects, operating styles, work or other things based on the needs of the team.

I should be expected to provide clarifying information about “why” - especially when deferring responsibility to others on the team. I encourage people to ask “why are we doing this” and “what is the impact?” in order to understand how the work to be done serves the organization.

I should be expected to create a safe environment where people can share how they feel, ask for help, deliver tough news, and communicate freely. If I fail in this regard, then I’ve failed as a manager.

Below is a gathering of the most important mutually agreed upon statements about how we actually do work...

We are first citizens of Ramp, and then citizens of the Marketing Org.

 at Ramp is to empower marketing operators to use technology to do their best work. By serving as a cross functional, value-add partner, we bring cross functional teams together, create efficiency through technology and automation, and ultimately better enable Ramp’s Marketing org to save our customers time and money by enabling ourselves to do the same.

 is the term that describes our new way of organizing.

Marketing Analytics (No fun acronym 😭).

We own channels with our stakeholders where technical work on our platform or stack happens.

We work in the places our stakeholders work, including team- slack channels, Asana, Email, Slab and Drive.

 the “landing page” for all our artifacts. We kind of hate slab as a squad and prefer Google Docs.

We document core institutional knowledge on Slab. Everything else, esp. Tech specs and designs, in Google Drive.

We manage tickets and our sprint planning process in Asana.

We present a single Asana intake form, and operate as a single unit with our stakeholders, dividing and conquering behind the scenes, but assigning a single DRI to drive a project or outcome.

Marketing systems owns and manages a unified set of tools for marketing. We call this the 

Platform (sometimes called the “Martech Stack”)

Until now we’ve never had a defined method for Roadmap planning.

We believe our OKRs drive our system enhancements and platform transformations.

We align our Roadmap against OKRs and our stakeholders’ needs. In this way, our Roadmap usually follows the rest of Marketing’s roadmap.

We think about our area of work, COLLECTIVELY, as Marketing Systems.


 and Business Systems represents Ramp Systems.

At this time, with our current team size, individuals do work across ALL THREE domains. In subsequent sections we’ll talk more about what this means, domain ownership, and how that maps to the way we service the org.

A common question is “how does your org map to your platform?”


Both MarOps and MarTech support work on the Marketing Systems platform (Often called our “Martech Stack”).

We think about technical work, and therein the way we plan our Roadmap, as follows:

Operational Improvements (Run) - All responsible.

System Enhancements (Grow) - MarOps largely responsible.

Platform Transformation (Transform) - MarTech largely responsible.

Marketing Systems Coverage By Cross Functional Team

We have divided Marketing Technology into three categories of domain ownership: MarOps, MarTech, and Marketing Analytics.


Below is how we think about ownership roles by domain. This manifests itself in the following way:

MarOps drives weekly check-ins with Cross Functional partners. They capture requirements and tickets on a 48-hour SLA. Where needed, they escalate or bring in MarTech.

They are not a gate-keeper. Our stakeholders and technical partners can and should bring in MarTech to advise and support MarOps in system enhancement projects.

Escalations to MarTech from MarOps or our stakeholders/partners as needed.

*All means we are all accountable. We should jump on requests as they come. X is first DRI if nobody else is available.

** Where two people are listed, this is meant to show how we work across domains together. Typically the secondary person is a key support partner. As we scale the team, we would expect to further refine ownership to singular people to drive better accountability.

Marketing Systems Coverage By Tool (INTERNAL ONLY)

This is an internal representation of how we think about accountability among our platform, tech stack and tools.

Team Expectations, Operating Norms, and Team Organization for Martech at Ramp

Martech Team Expectations, Operating Norms & How We Organize

Background & Context

Sign up to see more