Janis Zech: Hello and welcome to another episode of the RevOps Lab. Hey, Janis. Hey, Philipp. So what are we talking about today?

Janis Zech: Yeah. Today, we're talking with Paul Kalenberger from HeyJobs. Paul runs his twenty five people RevOps team like a product management department, and we go deep on the frameworks HeyJobs uses to measure success and how they run the organization. This is a fantastic episode to help you think about how to structure and organize your RevOps team, so please listen and enjoy. Paul Kalenberger, hey. Great to have you.

Paul Kalenberger: Hey, Janis. Hey, Philipp. Nice to meet you. Hello.

Janis Zech: Yeah. Great to have you here. You know, we've known each other for a while and been following your work. Maybe you can give the audience a quick introduction about yourself.

Paul Kalenberger: Sure. So, originally, I come from natural science. I did a lot of chemistry, bachelor's, master's and then worked at uni for a while. Had a short stint in consultancy for two years where we helped automotive manufacturers with model based system engineering. And then again by chance ended up in tech. I really liked the fast moving side of it and then stumbled into revenue operations actually about three and a half years ago and since then have been doing revenue operations and product in different varieties at HeyJobs and still doing it and loving it.

Janis Zech: Yeah. Fantastic. I mean, super curious, like, if you could tell us a bit more about HeyJobs. How big is your team? What's the setup, how big is the company?

Paul Kalenberger: Yeah. So HeyJobs is, you can imagine it as a marketplace. We're trying to connect talents with open jobs at companies. And it's a two sided business. We have the talent side where we try to cater a good experience to talents that want to find a new job. And we have the company side where companies want to fill open positions. And our revenue operations team is located on the companies or as we call it employer side as these are our paying customers and we want to help make our go to market motion as efficient as possible. And the revenue operations team at HeyJobs as in any company has gone through some kind of journey I would say with a change of the size of and the journey of the company. So when I joined HeyJobs, we didn't have revenue operations at all. And I think three months in, we formed revenue operations. Back then CRO pushed for it, which I really liked. And somehow, I think by chance and by some circumstances, I ended up leading that team, which was like a big thing for me because I haven't worked on Salesforce before, for example, and then just dived into that. About a year later we decided, okay, need to professionalize this and split up the team into a strategy team and a systems team. And I became in charge of the systems team and started building this out as a product team basically. So looking at our go to market systems and processes as a product. And then my role was more of a product manager in the function of revenue operations. And then some time back we decided, okay, with the stage of the company, we need to unify all of the efforts to drive efficiency in our go to market motion. And we rebuilt revenue operations as a whole. And now we're I think around twenty five people with four distinct areas within revenue operations. Yeah, and that's where we stand right now and how we go forward in twenty twenty four.

Janis Zech: So I'd love to double click on that. Like, when did you do the switch between, you know, the technical and the strategy part? And then what are the four areas you have today?

Paul Kalenberger: So I think we did that switch to split it up around two and a half years ago, because we said, okay, we need to drive our strategy forward with consultants that have experience in building out strategies of companies. So we split up the teams and around half a year ago we merged the teams back together to holistically have this ownership for efficiency and effectiveness of our go to market teams. And currently our revenue operations consist of the four teams which is intelligence, excellence, technology and services. And I think intelligence, technology and excellence is very common in revenue operations. Our services team is something that I see really well fits into revenue operations but not many companies do it like that, I believe. And this team is responsible to basically solve everything that we cannot productize. Everything that remains manual work in our organisation is covered by the services team. They are the first point of contact for any requests from our sales teams, for example, and they have, I think, twenty different hats and solve a hundred different problems, but in a very manual fashion. And, yeah, they cover what we cannot cover with our systems, basically.

Janis Zech: So this sounds almost to me like you're having one team that is responsible for all the nitty gritty things that matter, but maybe are not strategic. Is that a fair view? I'm not sure if, you know, people would like to hear that. But, you know, I mean, to a certain extent, I think if you think of the idea of service desk, right, and SLAs, I think it's a very common structure. I'm curious how you think about that.

Paul Kalenberger: I mean, you said not strategic, and I would challenge that a bit because, for one, it's a strategic decision not to automate or productize the topics that they're working on. And the other thing is obviously from that team comes a lot of push to actually change processes or in the end optimize or really automate them because this is the team that is closest to the action and that realizes, hey, we're doing a repetitive thing. Now a pattern shows up. We can automate this. So there is some strategic work involved there. But it's all the nitty gritty where nobody else knows what to do. They come in and they pick it up and they do it basically.

Janis Zech: Yeah. And everybody who's listening to RevOps Lab, we are very deep in, you know, a trade of improvements. We think that's super important to build a better revenue engine. And in that sense, yeah, I think the idea of strategic versus not strategic is also a bit of a LinkedIn discussion I don't really like. But I think it's great that you have, you know, people who are looking more at maybe the mid to long term versus, you know, others who are really in the day to day, and you separate that out so clearly. I know Philipp is eager to ask a question, so I'll shut up now.

Philipp Stelzer: No. No. All good. All good. Two questions. One where I just wanna clarify sort of the ratio at HeyJobs, between, you know, RevOps and the sales org, or RevOps and the marketing org. Like, maybe we sum that up as one bigger group. Just curious about that. I think it's just an interesting stat to always look at and to understand because I think it gives an insight into, you know, how serious RevOps is taking and revenue excellence is taking at an organization. And then you mentioned, like, you know, product and that you build out the RevOps team sort of like a product team. And I'm just curious, like, you know, without going into the details already there, but just, like, what do you mean by that? Like, sort of, like, what's the underlying philosophy that you thought through for the RevOps team?

Paul Kalenberger: Maybe starting with the headcount part. I think this is — I like to look at these numbers for different companies also, but I find it's a lot of flaw in there because some areas might not be called revenue operations but do exactly what revenue operations does. So you see a count of one to twenty and you think, wow, these poor people, they have so much work. But then there might be another team that is actually covering a lot of this. I think we have around two hundred marketing plus sales. And with the services team, we're at twenty five RevOps. With taking that service part out, I think around fifteen. So yeah, it's a ratio of, I don't know, one to thirteen, one to fifteen kind of thing.

Philipp Stelzer: How many are in services? How does it split across technology, excellence, intelligence and services?

Paul Kalenberger: So services is around ten, a bit more than ten. Technology is five. Intelligence, we are ramping up right now. Going to be four. We are at one right now, so some way to go there.

Philipp Stelzer: Joint pullout?

Paul Kalenberger: Yeah, exactly. Exactly. We have open positions for that. And on the excellence side, we are four at the moment as well. Exactly. And then circling back, Philipp, to your product question. So I think running your tech stack as a product is super helpful because then you stop looking at, okay, we have HubSpot and we have Salesforce and we have Zapier and we try to connect everything, but you say, okay, we have our revenue platform or revenue systems and we use it to solve problems. And with that you go away from somebody saying, hey, I need this button in Salesforce, please implement it for me. But you go to a setup where you say, okay, let's talk. What is the problem you tried to solve? And then maybe we find out your solution doesn't match to the problem you actually have. And you can look at the system as a whole and say no, what you actually need is something implemented in HubSpot so a data point gets forwarded to Salesforce and then you can use it. And this way of thinking to put the problem first and dive into the problem very deep to understand what is the right solution for that problem rather than being super reactive as a Salesforce admin, for example, and just creating fields for people or buttons for people. This is one part of the product mindset that I feel is extremely helpful to implement in revenue operations. And then you also start thinking on how can you increase the value of this product you are internally delivering in the long term and not just put out fires in the short term. So this is very high level why I think revenue operations in general should be very product like, and especially on the systems side and maybe the intelligence side as well, actually.

Janis Zech: Okay, I have so many questions. This is the topic for today. So let's maybe kick off and really double click into all this a lot further. So are there specific frameworks you're applying for your revenue operations, planning and execution?

Paul Kalenberger: Yeah. I think first I want to mention that, like, I feel there's a hundred frameworks out there, and all of them themselves, they don't solve a problem, right? I think with the right mindset, you solve problems. But you can borrow from different frameworks because people tried things before and learned there's good ways to do this or not. And then you can pitch something together that works for you. And I think one super common example in product is scrum, right? There's a lot of scrum coaches out there that tell you, hey, use scrum and all your problems are gone. I feel there's a lot within Scrum with the right mindset if you use it right that has great value for you. But I would never go with a framework and say okay, we're applying this framework now. So in our team, for example, what we do is we have daily stand ups. We, some time ago, worked in sprints. So we have a Jira board. We had weekly sprints at that moment. We write tickets. We can dive into how we do that in a bit maybe. And then we would have a refinement session to make everybody understand what these tickets are meant to solve or what's the objective behind them and then discuss technical solutions. And then the engineering team or Salesforce team would go about implementing these solutions. And at some point we realized, okay, we need like these short sprints of a week, which is a bit uncommon because our go to market organization is moving very fast and they need things now and not in three weeks. So we had these one week sprints. But for the Salesforce admin team and the developers, that was not ideal because every week they felt okay, this is too big to solve. We are not there yet. And they tried to push out stuff very fast that was not complete. So one idea was, okay, let's go to two week sprints and give them a bit more time. And we played around with that idea and said, no, let's actually kill sprints completely and go to a Kanban cycle where we continuously move tickets through the board. That comes with different challenges also, so we need to make sure we commit to finishing things and we need a work in progress limit to make sure we don't have twenty open tasks with someone. But this weird idea in the beginning solved the problem in a very good way. So we are very much able to react quickly to changes in the go to market org, but also we have a way of tracking our work very well and making people commit to finishing things. So that was one thing that I really felt I wouldn't have thought that, but just trying it out really helped to ditching some of the scrum framework rules, basically.

Philipp Stelzer: I from a product management experience, I would also feel like Scrum often adds a lot of overhead, particularly if you have, like, a team where — I mean, if it's purely engineering, I think it can work. But then if you add other sort of functions in that and they also require to do scrum, then I think the overhead that it adds and the time that it requires to go through the process and respect all sort of the ceremonies that you do, even if you cut them short, I think it's just often not worth it. And if your team is really experienced and you have a good culture and these two things come together, then I think Kanban is just so efficient because it eliminates so much need for communication. I mean, still, of course, it's good to have communication going. Right? But it's just such an efficient way, and at the same time, it makes your work so transparent to the rest of the organization. So the marketing team — and I assume this is probably one of the challenges to try to solve — that the marketing team always knows where sort of like the asks and requests stand in the priority and, yeah, what the current status is really.

Paul Kalenberger: I have to say we can get better at that still, to give transparency into where we stand. But one thing you mentioned is super important. I think moving from let's say scrum to Kanban, it doesn't work with a very junior team that doesn't know how to work together yet. Because this commitment of I finish something at that specific point in time is super important with a junior team. But if you have established a good work routine and you can rely on each other, you don't need that specific end of the sprint, but you can do this in a Kanban way. And that is a good thing that we learned also that there's a right time to make that switch, basically, with the maturity of the team.

Janis Zech: I want to get very, very tactical here. So, like, do you have multiple boards? Do you have one board? Do you have multiple backlogs? How do you write your tickets? Do you have, like, accepted criterias? Yeah. Really double clicking in on this.

Paul Kalenberger: Yeah. This is continuously developing, right? We are trying and changing. The technology team for a while is using one board basically to implement things in our systems. But then now combining all the other areas of revenue operations, we don't want to force them to use Jira. For example on the excellence team, you don't have the natural need to have something like Jira to use to track your tasks. But what we do together is to prioritize objectives that we want to address as revenue operations, and we are using a discovery board for that where we basically enter our objectives and refine them together and distribute them into the teams, and then the teams decide how they want to pick up these objectives. They move them into their roadmap or their timelines and then pick it up from there. They can do it in a doc, they can do it in Jira, they can track the work however they want to.

Janis Zech: And how do you bring the roadmap together then? Right? Like, I mean, I think the this idea of RevOps discovery similar to product discovery is always fascinating to me. Like, right? Because it sets the tone of what you actually work on and what the impact is. So, I mean, how do you know what to work on? How do you yeah. And how do you track that and how do you structure that?

Paul Kalenberger: Mhmm. We're again experimenting with that at the moment. So from quarter four last year, we had quarterly planning where each team would basically collect the things they think is most valuable to work on. And then we usually had check ins with the senior management team and the relevant stakeholders. So everybody is aligned on why are we working on things and why are we not working on some of the things. And now we realize this is a bit of a burden to do that quarterly because there is always, you start the quarter still catching up with the last quarter, then you have maybe one month in the quarter where you can actually focus on working, but then already move into planning again and everybody has to align. So it never feels like you're in the good space. You're never in the let's deliver things space. So what we did now, and we still need to see how that goes, is to move to continuous planning. So we implemented this discovery board or objectives board basically, and every week check in on these topics and prioritize them together to see which are the items that are most relevant for the business. And now comes the part where we still need to get better. We now need to give visibility for the stakeholders into this and help them to very easily understand why is something prioritised and why is something deprioritized. We're using very simple frameworks for prioritization like ICE, but I have to say I like that as a general guidance, but in the end what happens a lot is then you adjust, let's say, impact, so the prioritization matches with your gut feel. Right? So you want to take gut feel out. That's where you implement these frameworks. And then in the end you're just moving around so your gut feel works again. That's something that is very risky, I think, and something where we are trying to get better in connecting impact to let's say a certain amount of revenue that we expect from this change. That comes with another downside, right, if you do ROI calculations, you can do them very fancy and turn up with okay, this brings us one million. And then you do it and nobody ever looks at it again. So it becomes a science of just inventing numbers that look good. So all of these frameworks have big downsides and you need to find a way of the revenue operations organization or any part of the organization having a transparent alignment with the stakeholders why things are done and why not. And I think it should be as simple as possible rather than hundreds of calculation cases done everywhere.

Janis Zech: Yeah. And your continuous planning process, I mean, who is part of that decision body? And, like, I assume you don't do it with executives every week, or do you do it every week? Do you have different forums where you basically make the decisions in the team and maybe in an alignment board or team meeting?

Paul Kalenberger: This is something that I really like at HeyJobs and probably part of why I'm still here. A lot of mandate is given to each individual area and team lead and individual, basically. So we are prioritizing the topics based on our understanding. And if we lack information, we get that information. And then we present this to senior stakeholders. In the past, we did that quarterly. Now we still need to find the right frequency. And it's then based on if they challenge that, we discuss with them why and try to understand and potentially reprioritize, because we might have missed some information. But it's on us to decide what we work on in the first place. And this is extremely helpful, I think, if you have the right people in place. You can step away from all of these sign off levels that you need to do for projects, right? Because you trust the people to do the right things. And I think one really important aspect on that is to have the right KPIs or internal metrics for the areas to enable that, because people need to know what are they working towards, right?

Janis Zech: Now, just curious, like, do you then also have something like release notes where you, like, then go around and talk to the sales team and the marketing team? Hey. These are all the things we changed. This is the changelog. You can, like, look at the latest improvements that we did.

Paul Kalenberger: Yeah. I would love to say yes. But I can't. That's also something where I think it's a conflict of having a lot of process in place and standardizing things, and then you lose speed by doing so. And I think we're a bit too unstructured in some regards still, but that gives us the ability to move fast. I think now we're in a place where we need to get better at, let's say, clearly communicating what we released and we're thinking about a weekly newsletter to inform everybody about changes that are relevant. But yeah, I receive a couple of newsletters every week internally and half of them is like, yeah, thank you for that newsletter. I'm not going to read that today. So it needs to generate value, I think. So stakeholders look at them actually and not just have them in their inbox.

Janis Zech: Yeah. Yeah. It's tough. I mean, that's always the challenge, like speed and, yeah, doing a bit slower, but then explaining everything really well and making sure everybody comes along for the journey. Yeah. It's always tough. Like, you mentioned, I mean, we talked about Kanban. We talked about Scrum. Any other frameworks that you apply? I mean, there's, like, I don't know, jobs to be done. There's OKRs, very common in product management organizations. Do you also apply those, or is Kanban sort of, like, the limit here?

Paul Kalenberger: We used OKRs some time back in the whole organization, and then decided to not do that anymore. One problem was that each quarter you get a new objective, you define new key results, you need to set up new tracking of these key results, and that makes you jump from one direction to the other, basically. And what we did then as an organization is we implemented eternal metrics as drivers. So each team has to define the eternal metrics they work towards, and they keep being there. You can change them if the market or the situation changes but they should be constant. And then you can decide is a project influencing this metric in the right way or not and decide if you do something or not. So I think there is a lot of power in OKRs but it can also go very wrong if you start using that. And I really like this eternal metrics idea that you define. And that's the complicated part. You need to have the right eternal metrics or KPIs for each of these teams. But then let them drive these metrics forward over a longer period of time and base decisions on that.

Janis Zech: Can you give a few examples of these metrics?

Paul Kalenberger: Yeah, maybe where we come from in the technology team is we have some main processes within Salesforce. Let's say closing the first deal with a customer. We calculated how many manual steps are required to do this. And then we said okay, within this next year we want to reduce this number. And each quarter we set like a target of we want to take out ten percent of five of these manual steps to give the reps more time back to actually do meaningful stuff. And that worked quite well on like two of the core processes. We did good progress and then we realised, okay, now we need to touch another process. We need to implement a new analytics or counting method for a new process. Now we are in the transition to changing that and saying, we don't want to look at individual processes and cut out manual steps, but we want to look at how much time do the reps have for meaningful work. So we flip it around basically and now we are implementing to track how much or how many meaningful activities per rep per month are we seeing in the organization, like calls over a certain duration or events with customers or meetings with customers. So now the technology team's focus is to bring that number up and to give them as much time back to actually have these meaningful interactions with customers. And they can do that by taking out administrative work. So the vision there is that Salesforce becomes the copilot rather than this thing where you need to enter data and that annoys you every day.

Janis Zech: Yeah, yeah, we've heard about that before. One reason why we started Weflow. And it's definitely something that is overlooked often and the norm for many, unfortunately. But yeah, that's a different topic. It sounds almost to me like you're flipping it around, right? You're basically starting with, okay, this could be the solution, but then, this is actually the metric we want to influence, and let's now discover what has the biggest impact on those metrics so that you can actually drive value. Is that a fair assessment?

Paul Kalenberger: Yeah. Yeah. Yeah. Exactly. That sounds totally right.

Janis Zech: Yeah. I mean, one remark I just want to make, because I find that is actually a theme when I hear you talking across the board is that you went from, you know, monthly or quarterly to almost like a continuous everything. Right? So and I think that is actually so important when you think of planning, when you think of, you know, execution, when you think of training that is actually continuously done. And the same is true with prioritization. Right? Like, I mean, Philipp and I, I mean, we actually worked very similarly to what you described in terms of how we develop our product. And it gives you a lot of flexibility to change the backlog without annoying the engineers. But at the same time, you're basically continuously doing it because you wanna react to your learning process. And that is also something that I think often is not factored in. And if you work in these monthly or quarterly periods, you're basically set. You spend a lot of time on planning, preparing, and then reviewing, evaluating, instead of actually doing the work. Right? And so I really love this general theme of continuous everything, because I think it's very powerful for companies overall.

Paul Kalenberger: Mhmm. I think there's a risk connected to it. So on the engineering side or with our admins, I obviously don't want to give them something new to work on every day, right? It's not okay tomorrow, it's dead, and then it's dead, and then it's dead. So this context switching is extremely dangerous, so you need to find the right frequency of pushing for different things. And ideally you have some visibility into what's coming next. Because, I mean, we don't want to send tickets to our admins and say work on it. We want to sit together with them and say like, hey, we have this problem. How would you solve it? What is your approach to it? What do we need to consider? And I think they are the ones that can actually find the best solution to a problem we have. And if they are just every day working on a new task, this doesn't work anymore. So this is the really complicated part and that's why I think you can do that in more mature teams that know how to work together already. We're trying this more and more and see good results, but I think you can overstretch it and maybe if we talk again in a year, I tell you, hey, we move back to quarterly planning because it totally failed.

Janis Zech: Yeah. Just maybe as an addition, I mean, so for us, the way we run it is like, I'd say the discovery funnel is very broad, but it follows specific themes. Right? So we have strategic priorities on the discovery funnel that are three to nine months out on the product side. But then as soon as it gets into selected for development, right? And even before in the backlog, it is very specific and it's clearly refined. And even in the refinement, we discover certain, you know, shortcomings or adjustments to the designs, to the flows, to ensure that we then can execute seamlessly. And then I think what Philipp mentioned earlier, how do you ensure that there's a lot of flow time, right? You're not overwhelming the people with too many things. So for example, we don't do daily stand ups because it's just time taken away from the calendar. Yes, it's ten minutes, but then typically it's twenty or thirty minutes in person. It's usually more thirty minutes. And it's a big group talking about stuff that actually is not unlocking anyone often. So it doesn't really make sense. Right? So people just write in the Slack channel. This is what I'm working on today. And then if there's a blocker, you jump on a call. Right? So it's also the culture you create on making sure that if you're blocked as a person, unblock yourself. And I think that's a bit how we run it, and I think it always follows strategic vision in terms of what you want to achieve. And yeah, but it's a fascinating topic and it's really hard to get right, I think. Especially in a larger org like you have twenty five folks.

Paul Kalenberger: Yeah, I think if you have areas where people touch the same stuff all the time that are very dependent on each other, these check ins can make a lot of sense. As soon as people work on stuff that can function independently, it's just a waste of time because everybody says what they're doing and nobody else cares, right? But for us right now it works well with these stand ups, especially in the technology team. But I can imagine a setup where we would need separate stand ups or a group that does that and a group that doesn't do that because I totally see your point. Our calendars are full with meetings and we try to get rid of them. And at some point, maybe stand ups are good to cancel.

Janis Zech: Yeah. I think it really always depends on the specifics. Right? At Fiverr, I mean, we had around one hundred engineers, like eight to ten people in product. We had multiple different streams any given time and a lot of time spent on actually strategic alignment and then execution on all the different streams. So I think it's always in context of size and structure and complexity. There's a lot of moving pieces. But, yeah, I think so many great nuggets. Okay. Now I'm talking again. Like, Philipp, please, over to you.

Philipp Stelzer: All good. It's all good. I think it's a fascinating discussion. Yeah. Just actually wanted to add one thought there. I think, like, the key thing there with Kanban is also right? Like, I think sometimes you have these urgent and important tickets, and they are just important because it's major defects in some process that just needs to be fixed. And that's it. Right? Like, I think that's something you just have to accept and then have to work towards just making that a rare occasion. And then for everything else, really, I think then the job from the product management or revenue operation side is to make sure that you can really explain the why the priority is so high. Like, and I think this is this whole thing of, like, having a really deep understanding of why are we doing this, what does it actually solve, what is the metric that we are, you know, working against here. And this is, like, the sum of all of this is the reason why the priority is this and this. And I think if you do it right, then it's basically impossible to give engineers like, can do tasks around so much all the time because, like, you know, if you take that serious, it's just not possible to create so many tasks that go into all those different directions. Just a thought. Just, you know, like, I wanna add in one more question before the episode ends. Like, product management is a lot about, like, talking actually also to customers, doing market research and speaking to the different stakeholders internally, externally, bringing all that together again, and then hopefully not finding a compromise, but just a really good solution that works for all. Also tough. But, yeah, just curious, like, how do you handle that topic, of, like, doing research, user research? Right? Because I think there's, like, in RevOps, there's, like, the internal side with the marketing and salespeople, and then but there's also, like, the customer side, like, how customers perceive their touch points with marketing and sales. So, yeah, really curious how you think about that.

Paul Kalenberger: Yep. It's a really good question. I think there's different layers to it, right? So one thing is internal versus external product, and I consider our revenue technology as a very internal product, because most of this our customers, like HeyJobs customers, never see. They experience a journey that we have part in designing, but they never see the systems themselves really. And this is a big advantage of an internal product. We have direct access to our users, which are our internal sales reps. So we can talk to them a lot. We sit on the same floor as they do. We understand if they complain about the system, we overhear it. We can jump in. We shadow them. So this is really helpful. And I spend a lot of time in thinking about the parallels for revenue systems or revenue technology and a product as you know it. And we try to define what are our customers and what are our users. And I mean, our customer cannot really churn because we are internal. They can basically stop supporting everyone to push data into Salesforce. They can stop using Salesforce as heavily. And if sales leads start tracking stuff in Sheets because the system doesn't work, that is basically what churn would be for us. So the senior management is for us the customer that we want to make sure keeps working with us. And then the users, for them it has to be feasible to use the system. It has to be usable. It has to add value to them. They need to know if I do that, I reach my booking targets, for example. So we have these two groups. And I have to say we are, as revenue operations at HeyJobs, very little in touch with the