James Darragh

I hit on this somewhat above but generally it should be * 30 Days: Learning and Discovery * Meet with key stakeholders (Managers and ICs) to learn current processes, bottlenecks, and paint points. Since ops roles are very cross functional, make sure you are meeting with people not just in your direct domain (sales ops people should meet with marketers, marketing ops with sales folks, etc.). Get to know the business - what’s humming along and what areas need your attention. * Spend time on general company and product knowledge - it’s so difficult to make time to learn and gain product expertise after you’re working on ops problems. * Make a backlog of asks and prioritize them with your manager; identify 1 quick hit (ideally with a stakeholder-facing solution) you can execute on in your first month. * If you have an internal data team, spend time with them to get details on where to go to self-serve your data requests (e.g. which field do you use for pipeline date, what is the source of truth for churn metrics). Put your knowledge to use and pull reporting for an upcoming meeting. * Document any processes that you uncover and the answers to questions you had (especially if somone had to give you a verbal answer). This will help the next hire ramp more quickly. * 60 Days: Contributing * Distill your findings from month 1 and prioritize your first 2-3 larger projects that you’ll be working on. Scope effort and impact and get buy-in from your manager and stakeholders that these are the biggest asks for you to be working on out of the gate. Start executing! * Define your OKRs (either on the above projects or aligning with the ongoing company schedule and planning process) * Take ownership of key systems or processes (e.g. taking over as admin of your CRM, Support or marketing automation tool). * Share out your progress to the wider org (ideally complete 1 of the larger tasks you scoped) and document your work. Ensure teammates know how to engage with you and to get asks in the ops queue. * 90 Days: Planning and Taking Initiative * Iterate! You should be up and running and have a good understanding of business drivers, logic and reporting by this point. Pinpoint areas where there is friction and try to remove it. * Work on shifting from doing reactive to proactive work (from responding to a “I need help with this quote in CPQ” ask, to “Here are some enhanced flows that will make the quoting process easier for everyone”). * Look ahead 6 and 12 months down the road - what are the big rocks that the company is working towards during that time and what ops needs will they require? Anchor some of your projects to these further off goals or it’s difficult to make time for longer-term work when being inundated with ad hoc requests.

Rev ops should be a Day 2 hire - the systems and tools a company are implementing from very early days (e.g. SFDC) would benefit from a dedicated operations person to ensure that things are being built for scale. I may be biased as an ops person myself, but I think it’s extremely important to invest in these resources early on. I’ve never talked to a leader who says ‘I hired my rev ops person too early,’ but have heard many people lament the opposite. Practically, I think that after a company has gone from founder-led selling and there is a sales leader with 1-2 sales reps on board, it is time to hire a rev ops manager.

I think the biggest surprise is what you take for granted when rev ops is already an established function. The problems and decisions you make affect many more people at an established org - but they are very different in scope (instead of deciding accelerator percentage buckets on a comp plan, you’re thinking about how to pay people commissions in general or if accelerators should even exist). The decisions you make when establishing a rev ops function set a precedent that people will look back on months and years down the road (once you make a decision to add accelerators, it’s very hard to pull that back, for example). Also those decisions can be made relatively quickly and unilaterally when you are establishing the rev ops function (defining sales stages and exit criteria is much faster when it’s just you and a sales leader working on the spec, but that groundwork is extremely important and overhauling the process to just change a stage name for something different down the road is a lot of effort with little payback). So invest time in thinking about the future even when you can (and need to) move quickly. At the beginning, the scope of your role will be much wider but more shallow - you’ll be doing admin work in SFDC, helping marketing with a campaign list and a sales leader with territory planning - but then as the team and company grows, you’ll have specific people doing each of those functions going deeper than any one person could have when you were a team of one. 

Focus on getting the big systems in place first (on the sales side, for example, think CRM, data enrichment, sales engagement platform) and audit all the existing tools and processes currently in place. Ripping and replacing part of a tech stack is painful, but the earlier you make this decision, the easier it will be - so getting these tools procured and set up early-on is important. If you already have the main tech-stack pillars in place, ensure you have all the ‘future state’ tracking you’ll need (e.g. you may not need to report on stage by stage conversion rates right now, but you definitely will in the future, so ensure you are stamping the correct data points and stage details now to make life easier for future you). Meet with all of your direct (and indirect) stakeholders in your first weeks on the job - and make sure you have ongoing meetings with functional leaders. Identify their bottlenecks and pain points to help inform your first priorities - I guarantee there are some easy quick wins you’ll be able to knock out right away - this will put you in the team’s good graces and also help you create a backlog of larger items you can focus on in the next 30-60 days.

The org structure I mentioned really lends itself to working cross functionally. Our marketing ops folks are embedded on the marketing team and work together to create and cascade down quarterly OKRs and KPIs. The quarterly roadmap and project plans are built collaboratively and team goals and metrics roll-up to our larger company level OKRs. We have several ongoing synchronous meetings and async updates with key stakeholders (one on leads, one on pipeline, one on SDR work, etc.) as well as quarterly planning sessions to ensure everyone is aligned. For the most part, the rev ops OKRs directly support those of revenue marketing / demand gen (e.g. the marketing team is tasked with a field pipeline target, the ops team is responsible for orchestrating the campaigns, tracking and the reporting that help the field hit that target so they both share the KPI).

This is a great question - so many things about talent retention have to do with the company as a whole vs. things that I have control over on the operations team. So the first thing is to join a company that aligns with your values and where you believe in the mission and leadership; retention is much easier if it’s a great place to work! On the ops team in particular - make sure your team is working on projects that interest them, that they have a voice in setting their roadmap and OKRs and that you share context from other business units with your team to highlight the importance and impact of the work they’re doing. Also, if there are parts of the job that someone is particularly averse to (e.g. software procurement/negotiations) step in or offer support so they can do more impactful work. Unless it’s a key responsibility of their role, doing some lifting on those ‘less exciting’ tasks can go a long way. Finally, run defense for your team whenever possible so they have less thrash and can focus on their work and not on bureaucracy or fire drills.

We have a centralized ops team at dbt Labs - rolling up to the G&A org. I've worked in both siloed and centralized operations teams in the past and have a strong preference for a centralized structure (i.e. all rev ops functions roll up to one leader vs. marketing ops rolling up to a CMO and sales ops rolling up to a VP of Sales). The rev ops team is broken into specific functional groups (marketing ops, sales ops, CS/Support Ops and Business Systems Engineering). Our functional roles are 'embedded' into their respective teams (e.g. our marketing ops lead is part of our marketing leadership group and our VP of marketing takes part in quarterly reviews for that role). So although marketing ops does not roll up to the marketing department, most of his day-to-day work and stakeholders are on that team. This centralization allows for several benefits: * Unbiased decision making and reporting - ops can remain truly objective when not rolling up to a department lead * Less duplicative work - there is a lot of overlap between rev ops projects so this allows for better project management and coordination of our technical resources * Better communication within the ops team - we aren’t getting conflicting asks from different leaders and are able to work more collaboratively with this structure