In episode 5 of Swimm Upstream, Host Tom Ahi Dror speaks with Yuval Perry about managing one of the guilds responsible for Wix's backend as Head of Backend Engineering. Yuval talks about ensuring his team is on the "paved road" and how guilds help software organizations scale quickly and efficiently.
Hello, everyone, and thanks for joining us on this episode of Swimm Upstream, a podcast devoted to engineering team leads and dev tool enthusiast. I'm Tom, co-founder of Swimm, and today we're talking with Yuval Perry. Yuval has 25 years of experience in software engineering if you don't count coding, when he was still at middle school. In the past four years, he's held a senior engineering role in one of the fastest growing software companies in the world - Wix. In Wix, he manages one of the main guilds responsible for Wix's backend, which is incredibly complex. Some of you might be wondering what a guild is, and we will get to that shortly. Some of Yuval's main challenges include development, velocity, and knowledge sharing, which are also some of our favorite subjects on this podcast. Hi, Yuval. We're excited to have you on; thanks for coming to speak with me today.
Hello, glad to be here.
Okay, so to start you off. You should know that in Swimm, we take coffee very seriously. So if you could have coffee anywhere or with anyone today, where or who would it be?
Okay, so it's an easy one for me. For me, it would definitely be Minnesota. Because my wife's family is from Minnesota, and for the past several years, our yearly vacation is happening in St. Paul. And apart from the fact that Minnesota is, I think, one of the prettiest places that I have ever been, especially in the fall when you travel. I think we do the something we call the "do nothing" vacation, you know, no to do list. So we just stay with the kids. We order arts and crafts from Amazon, and we just hang on the carpet. We do one activity a day outside, but I recommend it to anyone with small kids.
Do you stay there in the winter as well?
I will not stay there in the winter, but the fall is a recommended time.
The fall is a good...Okay.
You know, the Indian summertime, where the leaves are taken over the shapes and colors. Yeah.
Absolutely. That sounds great. So, we'd like to know a bit better what you do. So please try to describe what you do now at Wix, but don't use your title.
Alright, so I have a few goals. Maybe I'll share two responsibilities. One is being responsible for the development velocity and development experience at Wix. This means that we track time developers take to develop features. And we collect their feedback on the experience, and we try to deliver a solution that will enhance both experience and velocity. So that's one. And the other one is creating a highly professional organization. This means that we need to build the standard together to create info solutions and also create a call. I call it an internal engineering community inside Wix.
So if I understand correctly, a guild system creates a matrix right in an organization where you have people in charge of products or verticals of some sort, and you have guilds that are responsible for professional areas, right. Is that true? Is that the way it's built in Wix?
Yes, I think quite similar to what you said. I think we can talk about the guild goals. And as I said, it's creating a highly professional organization. And we do this. It's like the old guild system - you know, in medieval days. We created the guidance and the standard. And we are creating guild-wide activities like think tanks or knowledge sharing groups to help us understand because, you know, not all of us are writing customer-facing products or info, so we choose the gallon together. And then we gain infrastructure for mutual projects. Our focus really is on velocity, resilience, performance, and development experience. And this helps us create a community where we can establish ongoing processes to earn these values.
What's the name of the other type of vertical? Is it product managers?
No, no. So we call it - we call them with the guild and companies. We call it companies, and it's...
...important name because it sends the message that the company has everything to succeed - it needs to succeed. So it has product managers and QA and front end engineers, server engineers, business analyst, everything. Because we don't know how to manage 6000 people, we know how to manage 150 people to achieve a goal. And then we have the company-wide look over professions like product fed font and server, and these are the names.
So everything you said about the guilds sounded to me - I mean, that's what I was expecting. But when you mentioned velocity, I was kind of surprised. Does this mean that, like on the company level, they are less interested in developer velocity?
No, but I think it's a wide thing that many time... Locally, you can’t solve it, right? Because you are forced to follow regulations like European regulations or GDPR. So you need somebody to take a wider look on it, and then measure if it's successful or not, because this kind of stuff usually slows down companies, and not part of the business logic, right - regulation that they should enforce. So it's one aspect of velocity.
Okay, so there are issues that are common to, for instance, backend developers in Wix that relate to velocity that you can see on a wide scale and try to solve them that way?
Exactly. There's a term I learned from Netflix. We call it the “paved road,” and we use it a lot, okay? The paved road - it's the road that we find like this: it's the road that 8% of the engineers spent 80% of their time. And we need to find it. So we send people globally, you know, company wide, to find it. And then we have our goal is to make sure that people that are on the paved road, and are in our case, it's like building a microservice, right? So you need to build it, you need to put a regulation we mentioned, you need to send domain events, you need to do a lot of stuff. But once you're on the paved road, then you need to make sure that the engineer has fast enough pace to proceed or he enjoys it. And it's okay. Not to deliver the best experience once he's off the road with our eyes on the paved road.
Okay, that's an interesting concept. Okay, so stepping away from velocity. Now, during your time at Wix, the software organization, and particularly your guild, grew substantially in numbers. This has been happening for years now, that Wix has been growing very fast. How does a guild help a software organizations scale well?
It's a great question because we definitely see scaling our organization is one of the guilds main goal, okay. It's on our table every day. And it's worth mentioning that we always see growth as a threat to a company because, you know, the line that adding a salesperson to a two people team, it's not only adding 50% of the workforce, it's also adding 50% more communication, right? An organization can drown in internal communication. And it's not effective. There are many ways to do it.
So we do a lot in this area - especially the guild is doing a lot. Because we think now it's like more than ten years, we have the guild structure, where it's a very mature faction in Wix. So again, we create - now we can enforce company-wide, or maybe regulate company-wide processes. So we create standards for recruitment - you're being recruited two Wix no for a team. And then the whole guild members, not the management, is defining the stages of the recruitment. And every two months, they meet, and we have a meeting where a stakeholder presents the conclusions, and takeaways, and tasks to extract. And we monitor each step of the funnel with KPIs. And we also do this for the onboarding, okay? The guild is responsible for the onboarding.
So we collect requirements, define the goals for the onboarding, monitoring, and when we treat it like a product basically. Then the other stuff that the guild is doing is identifying missing infra and implement them. And one last thing we do, which is, I think it's also important, is that we manage all the internal mobility because we invest in people, we want them to plan their career inside Wix. We have a very high retention, and we stand in the intersection of each mobility to make sure it's successful.
So people usually move between backend roles, for instance, and not pass between guilds. Is that true?
Usually, usually, but also people you know, sometimes an engineer wants to become a product or more to become a frontend engineer. So we handle it.
So that's a good segue to talk about onboarding that you mentioned. So, and obviously, this is a significant aspect of guilds, creating a smooth onboarding experience for new hires, right? So if you had to give like a really small number of tips for someone in a position like yours about creating a smooth onboarding process, what would you tell them to focus on?
Alright, so luckily, I have a lot of tips for planning onboarding because it's one of our main focuses. I will explain why. So the first one would be don't copy, okay? Don't copy it from another company. It's so...
Stop listening to me now.
No, no, don't copy from - from I don't want to mention other companies because maybe they are doing great, but don't copy because it's site dependent and culture dependent. So build something for your own culture. So gather your.... you can copy this - gather your people and discuss what you want to achieve, right? I can share what we decided in our case - we gather the team leaders first decision was put together, so we gather the team leaders. And then we talked about what we want to achieve. And our goals were that we want every onboarder to have worked through, you know, to work through our basic service building blocks. And another goal we had was to make it self guided. And this is a really important goal, because it triples the cost, making something self guided. But you know, COVID bursted, and we enjoy it, and why it was proven instantly, but it was...
So this happened before? The decision was made before COVID? Okay, so yeah, so you are probably very happy about that decision.
Amazing. It was a great decision. And then we have, like, small decisions like spoon feeding - when to spoon feed and when to make it more challenging, right? If it's like, internal infra[structure] that you must do something than spoonfeed it. If it's like an exercise, you can make it more challenging, more interesting for the user. And having it in the same voice, right? Because in organizations, one group does monitoring, and one group does service creation, another one does AV testing. You want it to be in the same voice, okay? For the experience. So how are you going to build a process around it - but the goal was to make it sound like, same voice.
And then the last goal was like - it was keeping it up to date. So we had to do a think tank or an organizational process on how to make it up to date and came up with great, you know, ideas on how to do it. And so the one thing is don't copy and have a discussion. The other thing is assign a stakeholder. And this is maybe the most important tip for my size of an organization. It means that, once you have a great stakeholder who is responsible for the whole onboarding process, he'll do stuff - he'll do like every three months a meeting where he’s going to, you know, show his takeout or conclusions, and then there's going to be a discussion of what to improve. So have a stakeholder. If you have a great stakeholder, he will put it on the right path, right?
So this is a person that will also be measured on the success of the onboarding process?
As I said, it's a product. So what we did - again, the implementation is different, practically. What we did is that we decided that there's going to be an infra team responsible of it, but it's going to be in shifts. So every six months, they’re onboarding somebody who looks wider on all of the countries - you know, people on board in every country in Wix - so he is going to look at it, and the team is going to be responsible to collect feedback, and apply exact tasks and apply them.
So this is on the stakeholder and the team who's currently on it. The last one, I would say, always work with feedback. This is like the last point on how to not make it stay because this is like something that we care a lot on. So you have to sample onborders. In my organization there are like separate people a month that are entering - more than 10. And we need to sample like two or three and ask them how was the experience and what was missing. And we need to expect tasks from this. And this is like an insurance that it doesn't go stale. So if I'm to summarize, so assign a stakeholder, define the goals, your eyes should be on the paved road, and collect feedback, and you are yourself on the paved road.
That sounds glorious, actually. I mean, I'm assuming a lot of people listening to this are thinking, wow, that's an amazing onboarding process and a lot of thought I've been giving to this. The onboarding process at our company is almost nothing compared to that. And that might create some frustration for our listeners. So, I talk with a lot of people about onboarding, and you'd be surprised how many of them describe their onboarding process as a checklist - somewhere - that a new person goes through, and if you're lucky, they mark what they did and what they didn't. Which is very, very, very far than what you described. And for an organization like that, starting from that position, and wanting to start the long road to reach the amazing state that you're in, what would be like the first step? It might be, you know, having a stakeholder like you described, but would you choose something else?
So first, I would recognize what are the gains of great onboarding? So there's one gain - obvious gain - which is a great experience for a person that you put a lot of effort to recruit, right? And you don't want him to come out frustrated from this process. You'll get worse engagement with the company, let's call it, right? But for me, it was like a side effect. The real goal was once you have a great onboarding. I also managed the info groups and guidelines to how to write a Microsoft.
So once you have an onboarding, you have already been through the past that you put all of your, I think, senior engineers, and they agreed on guidelines. And the guidelines are hidden inside. And right now, we don't have a sample service in production because our onboarding sample, and you would be surprised how many senior engineers go into the onboarding just to see what are our recommendation on monitoring. So what I really care about is having explicit guidelines - how to deploy - what I care about right, fit for my organization: how to deploy service, how to monitor, how to send events, how to connect webhooks, how to monitor it, and this is what I gained from the onboarding.
So onboarding, one of its side effects, might be a better software engineering process?
Exactly. Exactly. And, and another side effect is having, you know, more happy onborders, but it's just another effect, right? Not equally important to better engineering.
Okay, great. That's a good tip. So, unfortunately, that's all the time we have today. Yuval, thank you very much for coming on.
Thank you for having me.
Thank you, everyone for tuning in and I hope you join us for our next episode. To find additional episodes and full transcripts, or if you'd like to be a guest on our show find us on our community page at Swimm with a double m dot io. Bye for now.