Process Design with People at Its Heart

Shiran Duchovny, Global TA Ops Manager at Monday.com:

Hi, everyone. I'm very excited to be here today. So a little bit more about me. I joined Monday almost a year before this date here. I was pregnant with twin boys and gave birth at thirty-two weeks, which was definitely not my original plan. October 27th, as it says here, was my first day back, 2.0, at Monday to my dream role as a global operations manager, which actually meant managing talent acquisition cross-project and supporting our growth at scale.

Considering I only got a chance to work at Monday for three months before my mat leave, I basically came back to a clean slate. Not to mention that this was a first of its kind role at Monday, which was an amazing opportunity for me, but also a very big challenge. And it's almost an instinct when coming and starting a new role at a new company that you need to deliver and prove yourself fast.

You look back and borrow ideas that already worked for you before. How does it look like in real life? Imagine you step into a new rec ops role, and the list is endless. Your role is to build, standardize, turn everything into a process, and funny enough, you might even feel confident. And reach out for what you already know that works, the playbooks you've seen succeed or the ones you built yourself somewhere else.

For me, it was big companies. Intel, Meta, where I already seen processes at scale. And it doesn't matter where, the instinct is really usually the same. You borrow the proven thing and try to implement it and install it here in this new place. The trap with this situation is that the borrowed thing was proven somewhere else.

It can have the fingerprints of another company and another culture, and it wouldn't necessarily fit the culture and the company you are at now. And Monday taught me that, and very, very fast. I went deep, investigated, mapped everything I built very, very carefully, and someone told me flat out, "You know, here at Monday, this is not going to work.

Until you finish, it's just not going to be relevant." Monday moves fast. My instinct was too slow and too imported, especially for a company like Monday. Another call-out was that you should take under consideration Monday's culture. It's something that makes it the unique company that it is. And to be honest, it took me a moment, but I knew I wanted to build processes that worked, so I started trying to understand where people were coming from.

Their resistance wasn't people being difficult. It was actually people protecting something real about what Monday and the company is. So, the main lesson was that the process that worked here isn't necessarily the best I've ever seen or built. It's the best one this place will actually adopt. So, how do you do it, and in scale?

Reshape it to fit the culture. Sounds really nice, but how do you know that if it fits, and without taking too much time to find out? And how do you do it when the change is replacing the entire system the whole company hires through? The one thing I'll tell anyone that's stepping into this is that you don't do it alone, and you don't do it by guessing.

You build it with the people who live it, and I want to show you now how that looked like when we rolled out our new ATS, Ashby, at Monday.

We went on this journey to replace the ATS, and this is the model we've used. Three steps and three groups of people that really made this happen. Proof of concept team, design partners, and change champions. And since we're talking about borrowing, this is what I want you to borrow from me. So, first, find them before you've built.

So we identified our people at the POC stage true to Monday's mindset, which is very collaborative and fast-paced. As the core project team, we looked at a few ATS in the market, but wanted to make a decision together whether Ashby was the right fit for us and how we operate.

We chose people who were tech-savvy, did the actual work, and were trusted by their peers, which is also very important. But most importantly, people who knew Monday but also had perspective from other companies, other teams, other systems. You really need to have this outside lens when you're making such a big decision.

Over a few weeks, we trained them on different areas in the product. If it's job creation, sourcing, scheduling, reports, we gave them two weeks in a sandbox environment to test the system and pull their feedback throughout. That's an example of one of the surveys we gave them. The impact was major.

We walked away with a team-wide conviction that Ashby was the right call for us. And by the way, their feedback that we gather throughout this process really help us through implementation and enablement. Second, give them real skin in the build. We called our second group design partners, one manager and one IC from each site or org for real representation.

And they weren't just a focus group. As much as myself or other people of the implementation team, such as HRIS or application engineers, are familiar with our hiring processes, we are not TA partners or sourcers or TA managers, and we really wanted to make sure that the processes we built really fit how we work.

So our design partners mapped processes with us, shaped interview plans, shared regional nuances, and built things out in the system. If you already implemented Ashby or another system in a previous company, you're probably familiar with the user acceptance testing. It's very, very technical. So once we as the core team finished our technical UAT, we built a unique one for our design partners.

The focus was on more specific recruiting and sourcing scenarios we have in Monday, and not just generic ones, and from opening a job to sourcing to preparing an offer, scheduling, and everything connected to the hiring process. We had two main wins from the design partners UAT. First, their feedback brought edge cases and unique situations that came from their day-to-day work that then we were able to adjust the system according to that.

It also flagged potential gaps we might have with the launch and with Ashby and address it throughout enablement. Second, finally, we had a chance to get them excited about Ashby. After talking with them for so long, they finally seen how it works. And third, turn them into change champions.

When we went live, design partners became champions. Some stayed on. New people naturally grew into change champions because some people are really just wired for it. So what is a change champion, and what makes it so vital for our team? First, they really bridge the gap between the strategy that we have in place to realize.

They're the one delivering the message to their teams and serve as first-line support for their peers, and they are able to surface the day-to-day friction we could very easily miss as the core project team. We equip them with targeted enablement, early access to updates, and expanded permissions, shaping them into the true voice of the ground.

And with a robust system like Ashby, their role doesn't really end. Given its ongoing updates and features like you've seen today and in previous updates of the system, champions are the one that will help enable the team, empower the team to adopt these new changes, ensuring the organization and your organization fully leverage Ashby's capabilities.

So coming back to this borrowing instinct, change champions was an idea I borrowed from a previous company I worked at before. I was a very proud change champion myself. It's not about the idea being new. It's about adapting it to the culture and company you are a part of now. So I encourage you, we found our change champions, now go find yours.

Thank you.