Ramp has a very direct and respectful culture, and I was able to say "Hey, I need everybody to read and comment on this," and that expectation was met. A lot of organizations don't have that, so I was really the benefactor of an existing culture around reading and respecting the written word. I think a big part of my own success in my career is that I believe that writing is super important to offload what's in your brain onto something that other people can relate to and understand.

The only expectation I had for this doc was that people would consume this information. I want them to respond to the information, and I want them to ask questions and engage. I have no expectation about them remembering this or that this is used as a universal doc day over day because very few artifacts, if any, are used on a day-to-day basis.

I think over time what's happened is that even if it's not talked about on a daily or weekly basis, there are moments where I come back to this doc and I look at the roadmap we have, and I can point to exactly where the problems are that we are working on.

I think around my one year mark, I'll come back to this doc and write a section called, "Where are we now?" where I'll say, "It's been a year. These are all the different roadmaps we had. This is all the work we've done. Have we progressed in solving the problems that we identified in the first month that I joined?" Already, I can tell you the answer is yes. 90% of these problems don't exist anymore because of the changes we've made, and I can actually link them to specific projects with specific tickets.

When I joined Ramp, there had been no strategic leadership in Systems. I was hired and expected to do something about it. This was my first attempt at coherently documenting the problems I was seeing. A lot of times with leadership at this level, it's not necessarily my job to fix all the problems, but it is my job to have a pulse on the holistic set of problems and to create a thread through them so that people can understand the problems that we're suffering from better.

One important callout is that when you're given permission or a mandate to do something about a big strategic issue versus when you just notice a problem, you have a very different ability to influence, persuade, and move the organization. You need to have an awareness of whose job it is to articulate the strategy. If I were to go and articulate what we should do for product, that's not my job and it may not be taken well because I was not hired to be our product leader. People can debate the merits of a culture like that, but that's just the way human organizations are.

Something I was dealing with was that when I first joined, I would hear people complain about systems, like "Oh, things don't work. We can't trust them. We're having issues, why are there always issues in Systems? That thing that happened last week is impacting our numbers."

There was a feeling amongst my peers and the people I worked with that our systems could not be trusted. There were problems with our systems, and there was not a good plan for getting away from that. A big rationale for why I did this early was to just signal to them like, Hey, I'm creating a clear hypothesis for what I think is going on, and it's gonna take a while to get us away from that. This was a signaling mechanism to just show and validate my thinking about everything.

The reality is, this is a pretty hefty document. It's pretty long. The other reason I did this was so if I ever was questioned or people asked "Hey, why have you not done more?", I could point back to this document and be like. "this is why it's really complicated." These things don't happen over night, so part of this strategy creation is put an anchor in the ground and say, "This is what I'm operating off of, this is the work I did to clarify where we are."

These are my peers. They are people who I would consider having the strongest, most valuable opinions related to the content of this doc. They are the experts with me.

These are DRs under us who have knowledge, and opinions we need to consider, but they are not setting the strategy. They also include cross functional peers like our head of data and infrastructure.

These are people whose opinions are included. I sent them this and asked them to weigh in and then revised the document and strategy in an effort to include their opinions that way they felt brought along in the journey.

One thing that's really important is that your style has to change as your company scales. In the beginning when you're a startup, you can get away with saying, "Our survival and ability to get shit done is far more valuable than debating the merits of something. We just need to decide. Let's elect a leader and let's go." In those environments, people are a lot more forgiving and willing to embrace uncertainty and rapid decision making because there's just so many fish to fry, there's no time for over-indexing on the journey.

But there's this really fast inflection point that occurs around 100 people where actually the journey and how you got there are just as important as the actual outcome because you're dealing with people's emotions and people's work. If you don't make them feel included, then you're going to be a lot slower. I'm the de facto expert in many parts of my job, but there are tons of moments where I have to work to get ICs 2, 3, 4 levels below me on board.

Even though that can be a painful motion for some people, you are establishing mutual trust with them. There's a give and take. You have to know when to put your foot down and say, "Hey, this is not a good use of time, here's why", and when to say, "Hey, I'm going to indulge this person or group of people because I need them to be bought in. This is the way that they want to do it and they have good rationale, then I shouldn't be so willing to dismiss."

I generally think "the why" in all work is an important piece of metadata that's left out by both the requester and the receiver. People don't want to be told what to do in general. Even if you're stating the obvious, you need to state the obvious for them to understand why you're requesting something or why you want to do it.

That applies to everybody, not just ICs. It applies to leaders. I would say an attribute of really experienced, seasoned executives is that they have the ability make everybody feel as if they are on the same team.

The key takeaway is that it's important to say to people, "I want your opinion, can you please chime in?" We also had a group meeting afterwards so after people had the opportunity to asynchronously read and reflect, we had a synchronous meeting where I asked the question again. You say, "Let me know how you're feeling. Does this make sense? How do you feel about the vision? What makes sense? Where are things not right?" And then you have to continually over time check in with them to see if the state of the world has changed.

The key ways where people go wrong when pitching a large technical project like this are:
- They don't provide context.
- They don't provide the business case.
- They don't create a clear case for why and why now.
- They don't showcase problems and the debt it's causing.
- They don't showcase net benefits of the future and how it will make company better.
- They don't include enough detail into why things need to change/must change to scale.

I wasn't suggesting wholesale tool burning. The devil is in the details of how tools are connected, operate, talk to each other and work. It's as much a human problem (how they use the tools) as it is a tooling problem.

DBT is a data modeling tool. HT is Hightouch, a reverse ETL vendor.

The process for developing these recommendations and tickets was largely me sitting over a steaming mug of coffee writing. This is highly sophisticated work and required both an understanding at a technical level of how our system works as well as the ability to craft a plan of making changes in a precise order.

One of the challenges is there's not a single leader who has supreme executive authority over all the resources for all of the Systems org. Systems is a loose couple of departments that all have a peer-like relationship. Even though I am the highest ranking person of that group, even though I have the most technical knowledge and experience, and even though people rely on me, I am not a dictator, so I don't get to just tell people what to do. Part of the rationale for why I created these tickets was to fuel other people to pick up work that I thought they should be picking up. It's a priming exercise. It was to say, "Here's what I think we need to do to do all this. If you're looking for ways to set up your roadmap, this is how I would do it and why." In particular, I'm being really, really discrete.

Part of servant leadership is putting the first draft forward. If I'm going to be the one who has this crazy big vision for how we need to change, it should be the expectation that I put some ideas together for the things we need to do to help us get there. I think leaders are less influential when they only do the strategy creation and not the tactics. I don't know if that's a widely held opinion; the classic business advice is that in order to scale, you have to move up and be more strategic, but there are tradeoffs to that. You need to choose carefully when to get tactical. I believe I'm a more effective engineering leader by continuing to wield both skillsets.

Even though I structured everything as tickets, we ended up doing the work organically. We had a shared language and started solving the same problems latently instead of explicitly.

The biggest benefit of creating this list was it served as an anchor for future work. We didn't immediately make these into tickets and do them all. Over 6 months we've slowly chipped away at the list. I actually haven't updated this in 2 months. Glancing at the list though, 90% of this is done.

Overall, I think this document was well-received. It really served as an anchor to guide our team and our principles. It set a vision for where we need to go. This propagated to many of my peers and leaders who subconsciously then aligned their roadmaps to things detailed in this.

These documents aren't always supposed to do anything - they can be great mechanisms to create clarity of thought, even if they aren't achievable all at once. They put a flag in the ground of where you need to go. Getting there is always messier than it may seem unless it's hyper prioritized across the org.

Austin Hay

I prepared this doc when defining Ramp's martech systems strategy. This artifact demonstrates how to drive alignment around a complex technical initiative and will be useful to PMs leading large infrastructure or tech debt projects.

(IE people who are going to collaboratively implement the changes to get to 2.0) - X, X, X, X, X, X, Austin Hay

For as long as most of the business team at Ramp has been at Ramp, we’ve been aware of the many challenges of our systems. In particular they stem from a reliance on 3rd party tools, interconnected in a way that is hard to debug, hard to manage and hard to transform.

1) Management means keeping the systems running in current state.

2) Transforming means changing the systems to make them better and reduce the amount of management we have to do.

As Casey Winters talks about often, the goal of all [System and Marketing] tech Operations teams should be to scale-ably make themselves obsolete by transforming our systems to require fewer human interventions

Our systems need a lot of work in the form of updates (in the tools, code, process)

 We keep piling on dependencies and requirements of management, leaving little time to transform the systems.

The broader team, especially leadership on Growth, Data, Sales and Partnerships, must recognize and consider in the context of OKR and goal planning 

. [It is my opinion] …we have the resources and willpower to change. 

What we haven’t had so far is time and focus.

Okay, bear with me. I’m going to put on my teacher hat. I think it’s important to align on some common taxonomy as we consider building a better system.

In my martech and systems Reforge course, I talk about 

4 key attributes of a growth, sales and marketing stack 

(varies depending on the business and how you slice it, but the attributes persist regardless).

: First, there is an element of redundancy that exists in any systems stack. Some redundancy in a stack is a good thing, because it gives you flexibility and optionality, but other redundancy is bad, leading towards an unfocused, clunky stack with poor data hygiene.

: Coupling is the reliance on a specific vendor due to the flow of data between vendors. Tight coupling is when one or more vendors rely exclusively on another vendor to receive data, such that if you remove the vendor, your other capabilities will break or cease to be useful. Loose coupling means the vendors are connected systematically to avoid bottlenecks surrounding a specific vendor.

: Interoperability is whether vendors could easily talk to each other, 

of whether you currently have them talking to each other. Interoperability is the ability to exchange and make use of the data by multiple vendors in your stack. 

: This is whether the decisions made in the stack solve discrete problems and are made with intentionality as opposed to an unfocused stack where vendors and data flows are added haphazardly.

I've observed the following stack attributes …

in Hubspot (crm, not email) and SFDC CRM and oppty management. 

Two tools doing the same thing, slightly differently, when we should be using 1 tool

in the 2 way sync of Hubspot and SFDC as well as Segment analytics instrumentation/Madkudu scoring to Lead creation and Routing.

Loads of interoperability, but wielded incorrectly. 

When our tools were set up, every tool was connected to many other tools, creating tight coupling.

for how to handle new technology needs. a) For example, haphazardly using Tag Manager, Zapier and Hightouch without having a clear strategy.

You’re probably thinking by now, “..thanks for the TED talk, but I have to actually deliver a number and communicate a plan to Eric and others.”

Totally fair! Let’s list the most important discrete issues of our stack:

Opportunity logic is managed in two spots, Hubspot and Salesforce. Because of this redundancy it makes troubleshooting, debugging and system transformation hard.

 back to any of our systems. Just as we can enable data in Google Tag Manager or Segment. We don’t have a clear philosophy on how we go about trying to enable data flows. An iPaaS tool will centralize how we federate non TOFU marketing data, but beyond this we should have a “how to waterfall” - meaning, a clear strategy on how we pass data and if the optionality doesn’t exist in our tool of choice, how we waterfall to other options.

We make use of SFDC Campaign Object quite heavily. But most of the transformations for this object occur in Hubspot. This tight coupling makes our attribution and system brittle.

. We have connected Hubspot to Salesforce for opportunity flag and creation as well as routing assignment. This tight coupling makes it very challenging to make system changes because you have to be an expert in both tools and have confidence/understanding in order to make changes that won’t have unknown consequences.

Because our systems are tightly coupled, when something is changed at the code level, in a workflow or system tool, it often has dramatic consequences that are difficult to parse. At the top of funnel we can instrument alerting to quickly be notified when breaking engineering changes occur. This is fast monitoring. At the BOFU level, we can set up daily alerting and generalized long-term trend monitoring to know when a system change has had an effect on a longer term horizon.

Vendors pride themselves in having integrations. And integrations often grant interoperability. BUT interoperability is a benefit that should be used with precision and care.

Today we have many examples of mismanaged interoperability - in other words, we’ve connected lots of tools to one another, creating spider-like threads between our systems. When tools become reliant in non-linear ways, it makes diagnosing issues very challenging. Examples:

Madkudu has connectors to Segment and Clearbit for its model. Hubspot and Segment talk to Madkudu. Salesforce also talks to Madkudu. Intercom talks directly to SFDC.

As much as possible, the goal should be to consolidate all data at the TOFU into our 3rd party CDP. This CDP should talk directly to Snowflake. From there or via a direct access pathway using an iPaaS tool, we should push and transform data to our CRM (Salesforce). Email tooling should simply receive data from our CDP (and perhaps our CRM).

This would decouple the following flows and make them more manageable:

Marketing activation (email) [CDP -> Email Tool]

Lead scoring/routing [CDP -> core.leads -> iPaaS -> SFDC]

Generalized data transfer/flow [ CDP/SFDC -> Snowflake -> DBT -> HT]

Martech and Business Tech can and should develop a process for how we handle incoming data and capability requests. Today this lives mostly in Austin and Justin’s heads about the “right” way to do something. We can document preferred pathways. For example in Martech, it looks something like this:

Then try to enable with Fivetran/Snowflake/DBT/HT

Okay, so by now we have a sense of why we are here, what good looks like, and what we need to fix. 

 to tackle each of the issues mentioned above.

Why does it seem like there are so many problems?

Well, to start, we do have a lot of system problems, but they are not all related. For example, recently in August, we made a change to our front-end code-base that made a core Segment event stop working. This will be fixed by one of the recommendations above.

Likewise, recently we realized that over time we had not been creating leads properly. This was hard to diagnose and fix because of the tight coupling, but 4.A. solutions would help us rapidly deploy solutions.

What would an ideal state system look like in 180 days?

We have an iPaaS tool where all non-martech data flows live (workflows).

We have removed all non-real-time marketing automation workflows (IE everything but things for email)

SFDC is the center of truth for lead routing and assignment.

We have a new chatbot tool that logs data to Segment and SFDC appropriately.

We’ve deployed our own scoring model and developed a separate “routing policy” that either lives in code or directly in SFDC.

We’ve moved the campaign logic and transformations to the iPaaS tool and/or SFDC.

Because logic is just in two spots (TOFU or BOFU; CDP or CRM) it is dramatically easier to triage issues.

We have alerting setup so we know the second something breaks, and the second a long standing trend becomes statistically significant.

How can we diagnose and resolve systems issues better and faster even with all this stuff?

When using data from Looker or Snowflake, refer to their underlying instrumentation names, or if a transformed event, the way you crafted that event.

Try to get all the data and information you can before considering there’s a problem. 

Avoid lengthy slack threads - work with X, X, X, X or X to establish an investigatory swat team so we can assign a project owner.

Any recommendations or resolutions → document in Asana or Linear!

Post back the details of what the problem was the solution in an IR or project document you started the investigation with.

Technical Strategy Planning Doc at Ramp

Technical Strategy Planning Doc

Background and Context ℹ️

Sign up to see more