Here, at Wix Engineering, we’re always on the hunt for technical challenges and personal growth. So, it’s no wonder that our Server Guild Manager, Yuval Perry, joined us as a result of his own journey of microservices challenges.
We sat down with Yuval to hear more about his take on software infrastructure management, development velocity, propagating knowledge, and his strategy for dealing with technical debt.
What is your engineering background?
I’ve been in the world of engineering for 25 years. I started my first professional job in the IDF. I am one of those people who always knew what they wanted to do.
I started coding in middle school and stayed hands-on for almost 20 years. A few years ago, I made the move to technical manager and I’m definitely enjoying the different challenges.
What is your role at Wix?
I am a Server Guild Manager at Wix. The purpose of the guild is to provide engineers with common technological and educational tools, promote best practices, care for professional growth and encourage sharing ideas across departments. We manage many guild activities like tech talks, round table discussions, and pair programming.
We constantly try to raise the bar in terms of professionalism, product excellency and development velocity (Want to know more about guilds? read here). I also manage the Wix server software infrastructure group.
Want to hear more firsthand from Yuval? Listen to his interview with Aviran Mordo on our Wix Engineering Podcast:
Why did you decide to join Wix?
That’s a very interesting question. I was working in a company that was doing microservices since 2012. We had more than 60 microservices in production and we were very proud of each and every one of them. We also built a very sophisticated CI/CD environment.
But, as we grew, we started to feel the load of their management. Meaning things started to break more often.
Since I am a very inquisitive guy, I started to investigate by making appointments with many super technical engineers from various companies that faced similar challenges.
I contacted Aviran Mordo (@aviranm), the head of engineering at Wix, who was kind enough to invite me and a few of my colleagues for a brainstorm. Right in the beginning he told us: “It’s very simple. You should start by deleting your integration and test environments”.
I didn’t know then if his answer was crazy or brilliant. It definitely sounded out of my comfort zone.
I didn’t know then if his answer was crazy or brilliant. It definitely sounded out of my comfort zone. Back then, we treated the integration environment as our last line of defense before production. As a result, we invested a lot of time and resources on it, and it still wasn’t very stable. And when the integration environment is not stable, the whole dev velocity becomes slow.
We started exploring new development processes that required only the production environment and the local dev station, and indeed, we started seeing some of the benefits.
Finally, when the business journey of my previous company ended, I contacted Wix again. I wanted to know how it’s possible to run a company with +1,400 microservices without an integration environment.
What are the biggest challenges you and your group are facing?
I have three main challenges as both the software infrastructure group manager and server guild manager:
Defining and prioritizing what should be done. And prioritizing it: Software infra group, by its nature, almost never has a customer facing product manager. So one of the biggest challenges for an infra group in an advanced organization, with hundreds of engineers, is to define what to do and prioritize it. You need to understand the company goals and strategy, participate in design reviews and collect feedback by meeting with engineers who use our products. In addition, you always keep some spare capacity for solving unplanned user needs as this guarantees you focus on the company's most important needs. I also believe that, as a manager, one should make some time to write code. I look for small coding projects that use our own infra. Since time is limited, I also use the guild week system in Wix to code.
Increasing development velocity: Wix is growing rapidly. And the saying is true: “when you add one person to a team of two, you don't only add 50% resources, you also add 50% more communication”. This can have a strong negative impact on velocity. So as Wix is successfully recruiting many great engineers each year, we have to keep up the delivery pace. Thankfully, we constantly measure our dev velocity to make sure we’re good and don’t regress. The fun part is that we always have more to do since we’re aiming for amazing!
Propagating knowledge: This is a big challenge in every rapidly growing organization. Because the real truth is that engineers, in general, write code better than they write documentation. And knowledge is not only documentation. It is also defining best practices, creating tools, and mentoring. At Wix we invest 20% of time in education and enhancing our software engineering skills. One of our favorite weekly activities, for example, is called ‘Guild Day’. Every week all engineers in the guild meet for a half day. We host tech talks, project spotlights, design reviews and hands-on workshops for all guild members. This activity does not only leverage our engineering skills, it also helps build our own community.
What lessons from your earlier career do you bring to Wix?
If I have to choose one, it would be “always pursue user value”. In previous positions, my users were mostly external customers. It’s natural to pursue user value when it comes to external business clients. The same drive should apply to internal products when developing software infrastructure.
I avoid developing features in a “dark room”. Instead, I engage as many users before the first release, at the earliest stage possible. Especially in the design stage. This has so many advantages, like avoiding over-engineering and adopting the “API First” approach - which we embrace at Wix.
This is also very helpful when facing tech debt issues. As a manager you will often be asked to allocate time for technical debt. I believe you should have a strategy for dealing with it. To begin with, I avoid starting any debt-related task without having to deliver another product feature in the same code area. I try to estimate the refactor benefits using other product features.
Thank you, Yuval!
For more engineering updates and insights:
Visit us on GitHub
Subscribe to our YouTube channel