I created this doc because when I was having 

a broader conversation about team expectations

 with one of my direct reports, I asked what he needs from me and he said "I don't always know what great looks like." I realized I was assuming that people know what's in my head. I also felt like this knowledge could be helpful more broadly.

We have a lot of young leaders at Ramp who are just finding themselves in their first management position. They end up managing a lot of people and a lot of responsibility. They're all very busy and have forgotten that the number one thing they need to do as a manager is coach and nurture people. So I decided I was just going to do this and put this together as a tool for multiple teams. I wrote this for my direct report it ended up being adopted by product, engineering, systems, revenue ops.

The intended audience for this doc is ICs age 22-28. This might be something you take and distribute to your team to set your expectations of what great looks like. It's probably not for a director or VP to consume.

I proposed these expectations and asked people to respond. A lot of folks at Ramp are early in their careers, hungry to learn and grow, but still needing the right mix of independence and support from their manager. How do you extract from them what they should be doing when they're looking to you for advice? I shared this to my directs and asked "Hey, does this resonate? If so, what resonates? What makes sense/doesn't? What would you change?"

Consistency is key to creating a healthy culture around deadlines. If you're consistently meeting deadlines, it makes not making them the exception. When you're consistently not meeting deadlines, it makes meeting them the exception. ICs and high performers should strive for the former. If you're a manager and you see the latter, you should engage to find out why deadlines aren't being met. Is it you as the manager? Are you setting unrealistic expectations? Or are you not holding people accountable (or are people not holding themselves accountable?).

By saying out loud what I expect, I've removed doubt or uncertainty from the equation. Now it's either me failing in my ability to predict and pace work, or theirs in their ability to communicate and deliver.

Federation refers to "federation of communications"–meaning sharing context, artifacts and outcomes vocally and textually with others.

In terms of where to record things, as much as possible try to align on how you work. For us it's:

- Asana to capture work and progress on tickets
- Slack for quick async or synchronous convos. Not the place to do deep technical work. Generally if a thread > 20 messages I nuke it and move to a Google Sheet
- Slab (kind of like an alternative to Notion) for "long standing company knowledge...." i.e., you are going to immortalize something

This naturally means we do most of our work in Google and then codify the important stuff in Slab.

Asana is the place where we do work, link artifacts together, converse on ticketing status, not the artifacts that may be linked.

"Control" can be a scary word, but I like and use it a lot. Control means the ability to control the outcome. When you're working on a problem and it lives in 2+ people's brains, it's really hard to control the outcome. There is so much unknown. There isn't alignment. Writing something down offloads it from your brain onto a medium that can be shared with others. This then allows you to align, create clarity, discuss, refine, create precision. This then minimizes the liabilities that this project won't get done - there is less uncertainty because you've made things more certain by writing them down somewhere. It helps reduce confusion because you can refer back with better precision to what you were talking about before.

In this example, a project has been swirling at Ramp for 2 weeks. We need an engineering team to help us build an internal email tool. Nobody wants to take responsibility. There's tons of bystander syndrome. So, I've escalated to our head of engineering, Nik.

I should probably make a framework for this. Good escalation knows when it should be public vs private. It's clear and direct without being mean. It links to the artifact or the work being done. It states the obvious (e.g., what is the deadline, why is it getting escalated), it gives people context around the escalation itself. And then this is a differential variable, but depending on the context, the escalation includes a lot of work to manage the perception and the outcome, meaning there are a lot of times where you have to DM 2-3 people so they're primed. Being thoughtful about how your words and actions might impact other people and taking proactive measures to mitigate the consequences is one of the most important pieces of escalation, and there's not a turnkey solution.

Some common things people get wrong when writing tickets are:
- Not enough context or information to actually service the ticket (aka ticket is general, not specific, missing information, lazily written).
- When asking for things they don't say why (people who are working in service of you deserve to know why so they can get closer to the context).
- Especially for data-related things people include screenshots that never have the information - it's so much better to include links to your data or the dashboard, not just the screenshot. BEST is when you do a screenshot or Loom explaining an issue and then you also include a link to the data so the person servicing the request can explore themselves to diagnose.
- No timeline or expectations of timing.

We have a razor-sharp process for triaging requests to avoid getting bogged down with unexpected asks from other teams. We communicate clearly when we will do something, when we won't, and when we expect we can.
We throw a lot of stuff away as "won't do" if somebody asks and then never follows up. We bake bandwidth into our work week by intentionally softening our roadmap (i.e., we set expectations on what we can deliver to account for unexpected work - that way we don't let people down and if we end up having more work we surprise and delight).

Austin Hay

This guide captures best practices and team norms around productivity. By setting expectations and giving clear guidance around what "good" looks like, this artifact has helped me improve my team's performance and has been adopted by teams across Ramp.

Martech Best Practices: Driving Projects to Completion

Ramp has grown quickly and now has many people with different skills and specialized knowledge. Often, it can be confusing who is responsible for driving the outcome given the nuanced way that each team member contributes to a project, task, or outcome.

This line of thought leads to some obvious questions: 

How should we as a cross functional team get work done? 

What does great project management look like and what are some of the 

This document is intended to try to capture elements of how some of our 

. It is intended to help educate all levels of operators (leaders to managers to ICs) on how to drive a project or outcome to completion.

This is a living document, and over time, as the culture, people and our operating norms change, this may evolve as well.

So, with that…. Let’s start at the beginning. What are our 

 around what it means to “get a project done”.

. There is immense clarity around what we are trying to achieve.

a. The outcome can be to learn. We don’t have to commit to boiling the ocean. But it should be clear what the outcome is.

Project is done on time. Projects have deadlines. Deadlines are taken seriously.

 People who fail to deliver on specified timelines should be able to credibly support “why” if deadlines are missed. We don’t shame when we miss, but we reflect and try to do better by exhibiting intentionality.

There’s never a moment where nobody knows who is responsible for the next step. At Ramp, we like RACI matrices. The R and A roles can transfer as a project progresses. It’s super important to publicly, explicitly state roles throughout a project.

. This means documentation around the basics, documentation of what work was done as it happened, and documentation or communication of outcome afterwards. There are varying degrees of detail and 

 to this end. What matters is consistency to meet the project needs.

General Project Management Best Practices

In Martech, Biztech and Biz Ops, we often are the PMs or drivers for a project. This means we 

, but we have to be clear about who owns what, and we have to be confident and comfortable holding people accountable to the work they have promised.

It is an expectation of our leadership team that when you take on a project, or commit to doing something that you will be held accountable to the outcome or deliverable. The way this manifests itself is in performance reviews. The 

despite our growing business needs, our organizational complexity, converging priorities, asynchronous and synchronous schedules is an expectation for those who want to succeed, thrive, and grow at Ramp.

Figuring out how to manage projects gracefully is an art, not a science. 

Different situations call for different tactics. And we all are human. Sometimes we do a great job of owning something end to end. Sometimes we don’t. Below is a crowd-sourced list of Project Management best practices that capture some of the “best” methods and generalized advice on how to get stuff done at a company of our size and stage.

Unless something is so obvious and easy to do in a moment, 

it is generally good practice to scope what’s in your brain to paper.

At a minimum, this is a “mini scope” or just a dump of “here’s what we are trying to achieve and why” and “here’s what I think we should do”

At a maximum, it’s a formalized project with a kickoff, GAANT chart, working docs for each stage, a project plan, business justification, technical scope docs, asana tickets, and executive briefing on outcome.

There is no “one size fits all” but generally as projects become more complex and have more value to the business, they should be controlled more judiciously.

When you feel like you can’t get something done, exerting control through artifacts, knowledge capture, tickets and reminders is a way to drive the outcome you seek. 

Understand who owns each responsibility in a project.

Be explicit, and clear about these owners. Don’t be afraid to ask the question “So who is owning X?”

If nobody owns something, be explicit in assigning ownership. If the person is not reliable in pro-actively delivering information or results, create a ticket to hold them accountable.

Verbal commitments are not good points of leverage. People are busy, we all have meetings. We all promise things in meetings that we never do because we don’t remember.

If something is important in a project, it should be ticketed.

If something is mission critical to a project being completed you should remind or check in with the person on a high frequency basis

A common strategy to shipping on time is working backwards. Let’s explore what this means …

Then work backwards in time, week by week and ask: “What would need to be done by this week in order for this project to be successful?”

Leave no stone unturned. Think about all elements of the project including scoping, aligning, seeking consensus, reporting out to the broader team, updating your peers, updating your leaders, potential blockers or delays, testing, shipping and monitoring AND [very important] communicating out again what has been done.

This is an important skill in becoming a high excellence professional. You have to be able to 

about getting something done on a timeline and then 

creating a structured plan for how to do it

Transitioning from IC → Manager → Leader comes with not making excuses for delivering, and taking responsibility for when you miss.

It’s okay to make assumptions about how long things will take, and to miss those when there are things you can’t control. What is crucial is that every week, every day there is 

to demonstrate that you controlled every element that you could. [Most of the time if you do this, there are no excuses possible].

When individuals are the blockers for a project, you are checking in with them on a 

. When they promise or commit to a day (2-4 days down the road), 

you’re setting a reminder and checking in with them

When individuals responsible for their parts miss what they’ve committed, you’re re-asking the question “when can we reasonably get this done?” “What can we do to help” and if necessary, you’re escalating it in the channel.

Getting shit done means being fearless and somewhat unapologetic in driving towards an outcome.

You need to leave your fear of perception behind. Ramp has created a place where talented people do their best work.

We are not doing our best work if we are afraid of what people might think if we ask them for a status update. We are not doing our best work if we don’t push a project or next step because we don’t want somebody to be upset.

Do not be afraid to ping people aka write in Slack “Hey X, in our call MM.DD.YY you asked about X and said you would do Z. What’s the status?” and … more important “How can I help?”

Being fearless doesn't mean being an asshole. It means being courageous to lead. And leading doesn’t mean putting the work on others. Sometimes you need to roll up your sleeves and jump in to help those that are blocking. This is the essence of servant leadership.

We talked earlier about the importance of writing something down. Creating clarity at the start of a project ensures that you can align people around a common goal. The same applies when driving a project forward. When you feel like you’re reliant on a person who isn’t moving the ball forward on a particular action item or outcome, explain why you need an answer and the timeline.

People can’t empathize or help if they don’t understand.

It’s bad practice to assume they have the same understanding of what you see in their heads. Usually when folks understand “why” they are more inclined to focus on “how”.

“We need you to do ABC for us to move to the next step or unblock DEF, do you have a sense when you might be able to deliver ABC?” ← Note: Don’t say “get back to us.” because getting back to you is not the same as delivering the thing they promised. Be explicit in what you want from them as an outcome: answer to a technical problem, an artifact, an action in some tool, delivering code or some change.

Escalating is an important skill in driving a project to completion.

If done correctly, you can get shit done and look like a pro.

If done incorrectly, you can annoy people and they will stop listening to your requests.

When to escalate: you should escalate when you’ve exhausted your options or patterns for getting work done, when you think something is wrong (financially, emotionally, or otherwise), or when you don’t know where to start or how to proceed.

Private Escalation is usually a great place to start if you’re not confident. Raise a question or the issue with your manager or a trusted peer. Ask what they might do, and see if they might be able to help.

Public Escalation is a great tool when you have a team that has trust and camaraderie. At Ramp, we should aspire to be able to fearlessly escalate in public.

Escalating does not mean publicly humiliating or blaming. It means calling out what is blocking the pathway to completion.

In a project you should strive to share updates publicly, that way when you ask for status updates and push for people to complete something, it doesn’t feel like an anti-pattern from your typical work.

Document your thoughts to drive clarity. 

Write down your thoughts in a Google Doc “Scope” or some other artifact as a means to create clarity. At a minimum, include …

Share the document and request feedback from all the people involved. If you don’t hear back, ping people again until you feel satisfied that a complete coalition of people is aligned.

Ask discretely “can you weigh in” or “... if I don’t hear from you by X I’m going to assume this looks good and proceed with Y in the recommendations”

As much as possible, ticket discrete promises that are actions. Tickets allow you to “offload” promises from your brain into a tool, affording you the ability to multithread.

When answering questions in Slack, if you know the answer and it solves the problem, confirm with the person that the problem is resolved.

Use tools to free up space in your brain and on your calendar: 

In Slack or email “Reminders” to push requests you can’t answer immediately to a time when you can. 

Recommended: Review your slack reminders daily. Snooze emails to prioritize your time more ruthlessly.

If something is more complicated and you’ll need time to investigate or do something, ticket it to the martech board. Then at the end of the day clean up your ticket or board. 

At a minimum clean up your tickets before sprint review.

If you need time to “think” put a time block on your calendar, otherwise you’ll never make time for it.

As a team respect people’s time when they require deep work.

. Do not wait for people to tell you what to do. Lead by doing. Infer what your manager or leader might expect of you and do it before they ask.

: The job of marketing operations is to operate - to help our business partners do more with less. 

This often means doing stuff that you didn’t expect in any given week.

 A campaign needs updating, a team needs help creating data trackers, a pixel needs to be added or modified.

There will always be stuff in our weekly work that we didn’t plan for, that needs to get done.

What’s important is to separate stuff into categories to action against: 

→ Prioritize on your schedule. Literally put a calendar block on your day to do what you’ve promised somebody you’ll do.

, but requires focus time to investigate, explore, understand → Prioritize the exploration on your calendar. Ask the stakeholder their expectations around timing and work backwards. If they need something next week, you should prioritize this week if the solution is unknown.

→ Requires deep work time to think, explore, learn, ask questions. Arguably if you don’t know what you don’t know, it's a great idea to start by writing down everything you do know, the questions you need to answer to get to a solution.

Then use the institutional knowledge of Ramp to help you. Talk to your manager, see what they know.

Ask the question: “Who do you think I should talk to that might know more about X?”

: The other important part of ticketing work is that it gives you a tool to drive accountability. You can ping people with the ticket and ask “what is the status?”

Likewise, when there is a complex project and you’re fearful about the outcome, documenting things through tickets shows measurable progress and provides an insurance policy around confusion, doubt, lack of progress.

Use tickets as leverage to drive the next step and demonstrate your progress. Be proactive in sharing both “what is happening” as well as “where you need help”.

Example of good project management in practice.

Pinging a peer or leader because they are blocking you.

Great recent example: X needed my advice on using Workato to stream livestorm data into Segment. He needed technical guidance. I was busy at Marketing All Hands and didn’t have enough time to answer him.

He got the PM (Y in this case) to follow up with me.

I didn’t find these messages irritating or offensive. Also if I did, shame on me. They are both trying to get work done and my advice is blocking them. I have two choices: either get back to them in a timely fashion, or delegate the knowledge/council to somebody else.

Not answering/not doing the work because you’re busy is not a good outcome.

Best Practices for Driving Projects to Completion at Ramp

Martech Best Practices: Driving Projects to Completion

Context

Sign up to see more