Platformization is technical, high-level work. But that doesn’t mean any talented developer can learn it like they would, say, a programming language. In fact, this kind of work is hardly about the technical details at all.
When Dan Bar-Shalom joined Wix, he became the second member of a two-man team. Together with his colleague Itai Chejanovsky, he had to organize an entire company of developers to work towards one, common goal - unifying code.
This was not so much a job for a technician, but a distinctly human endeavor. It was about listening to developers, making their lives easier, and helping them work better together.
In this episode, we’ll learn what it’s like to work in platformization. But more so than that, we’ll learn how to work with developers. Platformization may be a niche line of work, but getting people to work together is crucial to any team, and any company.
You can also listen to this episode on Apple podcast, Spotify, Google or on Wix Engineering site. And you can also read the full episode here:
INTRO TO DAN AND ITAI
Dan Bar Shalom is a programmer of twenty years. He worked in a few companies, and in one of them - LivePerson - he came across a developer he really liked.
So I’m Itai.
Itai Chejanovsky.
Itai: So when I came to LivePerson before I was at Wix, Dan was one of the interviewers and I found him to be very inspirational. It's like an interview that, when I finished it, I went home inspired and said, "I want to work at this company." And Dan was one of the reasons.
Dan: I actually interviewed him there and recruited him not to my own team but got him to the company and I really liked working with him. He’s a very brilliant guy and very – I really liked working with him.
It was love at first code--two developers swiping right on working with each other. But they were on different teams and, soon, their paths diverged.
Itai: I joined Wix about four years ago. I joined the platformization team as its first architect, and I was set to actually start the whole process of platformization in Wix.
If what Itai just said doesn’t make sense to you, it’s understandable. The word he used--“platformization”--is made-up. Not a real term. And it’s kind of fitting that Itai’s job title is gibberish, because the work he does is pretty unusual, too.
INTRO TO PLATFORMIZATION
To understand what “platformization” means, we first must understand that Wix is organized a bit differently from most companies.
Most corporations have a centralized command structure--one CEO, one executive board, a defined chain of command. Within that structure there may be divisions dedicated to different sectors--maybe a marketing division, an R&D division, and so on.
At Wix, what you’d normally think of as a division of the company operates, rather, as its own company.
Dan: The organization structure of Wix is actually many companies. Each product, you can call it a company, like e-commerce and bookings, et cetera. Each one is a company. And all of them were pretty much independent.
Each “company” at Wix is related to the others, but operates with a great deal of autonomy.
Dan: And that has worked pretty well because it allowed each company to move quickly without creating any dependencies between companies. So each one had their own product and their own R and D and everything.
Each one decided, basically, what they’re going to do and how they move. So that was the good part and it worked well as long as the company was small enough.
Imagine a team of six developers, working on a new software product.
If everyone works around the same table, in one room, you’re bound to have great collaboration, with ideas bouncing off the walls and each person helping one another. But you might get less work done when everyone’s hanging out. Two or three people talking about one thing might distract the others trying to work on their own thing.
You could put each developer in a separate room, and they’ll be highly productive. With quiet, no distractions, and no worrying about who’s looking over their shoulder, you’ll get some amazing work done in little time. But you lose some element of collaboration in the process. Each team member knows less about what the others are doing, and things which could’ve been hashed out in an argument, instead, go unsaid, and the remnants of that lack of communication make their way into the code.
Dan: The cost of this became pretty high because you realize that each company needs the same set of things. So they all need billing and they all need things like coupons and checkout and chat and other things, and because of this independence, each one of them developed it independently.
So it’s – for one thing, it creates duplication of efforts, so a waste of people’s time. And it creates inconsistencies in how the product looks and works.
When Wix was a small organization, dealing with each company’s idiosyncrasies wasn’t too big of an issue. But as the company grew, the issue compounded itself. Wix was like a minivan with a tractor’s engine, bicycle wheels and a clown car horn.
Dan: So our customers, they don’t really care about how the company structure is. They care about the customer experience. So for them, if they have two different billing systems or two different checkout experiences for their users, this is really bad.
This brings us to “platformization.”
Dan: So that’s a made-up word in Wix for, I think, the process or the overall move from let’s say one big mass of custom integrations between services to something more organized and, you know, a platform that looks coherent from outside and people can use it and understand how it works and understand the mechanisms and the different methods to use it.
PLATFORMIZATION PRE-DAN
Now you understand what Itai moved to Wix four years ago to do. And why doing it probably wasn’t going to be easy.
Itai: So the first part was defining how we want to tackle platformization in the system. After that, what we started doing is reviewing APIs with the different companies. So at that point I was reviewing like tens of APIs alone, by myself, which wasn't really scalable.
Itai was trying to do platformization for an entire corporation, across many companies, basically on his own.
Itai: So it was a tough time.
DAN AND ITAI RECONNECT
Meanwhile, Dan Bar Shalom was still finding his way in the startup space, with varying degrees of success.
Dan: After a few years, after I left the two start-ups, I was looking for a job.
Dan was told about a job opening at Wix. For platformization.
Dan: I think they were looking for maybe a few months or even maybe six months. It is very hard to find someone for this position.
And it’s pretty hard to recruit someone because, on one hand, you need very experienced people that can overlook the different aspects of the system and connect the dots on a very wide range of technologies and products and on the other hand, it’s kind of you’re not managing anyone. You’re not owning any specific system in production. So it’s very hard to find someone for that position.
He was hesitant about leaving startups and going back to a big company.
Dan: But I knew Itai was working there. So I just texted him and asked him if he knew anything about this position. And funny enough, he tells me, “You’re looking at it for yourself? I’m the one recruiting for that”. So we ended up pretty quickly, really - like 5 minutes after the HR call me and, maybe, a week later I get an offer. And I was very happy to take that opportunity.
Itai: I interviewed quite a lot of architects and it's very hard to find an architect that also sees high-level visions and is very good at APIs and sees the details and has enough experience to actually come into that place and be able to talk to people about the complexities and get them on board with the vision.
I knew from past experience of working with him that Dan had the skills that we needed. He was able to see visions of complete systems. He was very thorough, meticulous, and well-groomed on APIs.
It was really a blessing getting the notice from him that it was a possibility for him that he might join us.
After years apart, Dan and Itai teamed up again to run platformization at Wix. Now the team responsible for organizing an entire multinational corporation had...two employees.
Hey, it’s an improvement.
DAN’S EARLY DAYS
Itai: Anything that's, you know, you build, you start building small.
The idea was to start the platformization process and then gradually grow the team. Now we didn't have a final vision of how it would work. It was all building and seeing how far we could get and how far we could go.
Dan and Itai began their push to unify Wix’s systems. It didn’t get off to a flying start.
Dan: So actually the first – I think maybe six months or even more were very confusing. Like I didn’t know anyone. I felt kind of very lost. Many different groups, many different products and technologies and it was very hard getting a grip on all of this.
Obviously, Dan had never done platformization before, let alone on such a scale. He was lost.
DEFINING THE PROCESS
So he started with what he knew how to do and went from there. For example…
Itai: The first thing was to have common infrastructure and common terminology that everybody uses.
At that point, everybody was building something that's more akin to feature-based APIs. So you had a feature that you wanted to develop in some platform, whether it was booking, stores or anything else, you developed an API that was custom-tailored to that feature. And then your front end developers or other integrations use that API specifically. It amounted to having a lot of different APIs that did very, very small things, but no cohesive models.
Dan and Itai needed to develop what amounted to a gameplan--a rulebook--for all the Wix companies, and all their developers. It was a big job, but at a fundamental level, it’s something Dan had done before.
Dan: So in SafeBreach, when I started, I was the fifth employee there and we took maybe a week or two at the beginning to define and draw the high level vision architecture of the company.
We had nothing. We had code samples on like a POC that runs and we created this huge architecture that - none of it existed. Then in the following two years, it kind of – it was like the guiding map to where we want to go.
Everything we built, we always looked at this vision and we’re able to see if it takes us to that vision or not. And of course it wasn’t static. It was something that we kept updating and changing as we went. But we always had this guiding map to understand if we’re going in the right direction or not.
THE HUMAN CHALLENGE
Itai and Dan knew that developing an organization-wide rulebook for APIs was possible, so long as they had a clear direction and stuck to it. But this was actually the easy part of their job.
Itai: A lot of people weren't really used to modeling domain-driven in Wix, they're more like feature-driven. And it not only took the review part, but it also took the convincing part and making sure that everybody understands the premise and agrees with it.
Dan and Itai could come up with whatever rules and guidelines they wanted. But then they’d actually have to get everyone on board. They had to convince companies that had been doing things their own way, without having to worry about such things, for years. They had to fly to different countries to talk with hundreds of developers--people with their own preferences, quirks and needs.
Have you ever tried to convince more than two or three people of anything? How about getting hundreds of people to agree on one thing? Just the thought of it makes me sweat.
Nate: What’s harder, programming software or dealing with people?
Dan: Dealing with people obviously is much harder. It’s like you don’t know how the brain works. So it’s harder to program – you can’t program people, right? You need to find your way to them and a computer just does whatever you tell it to do.
Dan anticipated this “human challenge.” But, in a way, he’d been preparing for it for years. Ever since he left Intel as a young, sprightly engineer.
Dan: My last two years in LivePerson I was an architect and like I said, we moved from single service architecture, like big monolith, to breaking it into many smaller systems. And the company was already quite big. I think we reached about maybe 1000 people and I saw that you need a few things.
You need to find what motivates different people, what each person carries with him, what’s their experience, and when you actually talk to different people, when you talk to the groups, you start seeing, you know, small things, like what people think about doing things one way or another.
It usually comes from their past experience. Some people had to wake up at night because they used some database and now they are – they don’t want that database just because it made them sleepless in their past career. It doesn’t mean that it’s a bad database. It just means that for them, at a certain situation, it wasn’t good.
So you need to understand what different people think and why.
If the platformization team could understand their developers’ needs, and, crucially, the basis for those needs, they could create a system that actually makes everyone’s life easier. Rather than one that would feel restrictive, or fundamentally change how the developers liked to work.
Dan: I think most developers that I worked with are very logical human beings.
So if you have a good argument for or against something, usually you can get to an agreement. At least if you try to understand the logic behind what people say, then you can get to an agreement. You need to work for that. You need to actually listen and not just shout your opinion.
You can’t boss them around and tell them what to do. Anyway, even if you are their boss, it’s not the right way to go. You need to create that same alignment we talked about and make them see why you do things in a certain way.
The longer he stayed, the more Dan realized that platformization wasn’t really about the APIs. It was about the people who used them.
Dan: So I basically followed Itai. So I just shadowed him. We went together to all the meetings, met all the people. He was very good at introducing me to everyone and giving me the – you know, my place and taking things. I think gradually I felt more and more comfortable. And also the more people know you and the more there is trust between you and other people, then people start listening to what you say.
UNDERSTANDING PRODUCTS
It took many, many days--many conversations, arguments, flights to Kyiv and Lithuania and back. Dan and Itai met with more developers in a few months than most people meet in their lifetimes. And they couldn’t just talk, they had to listen. And understand basically everything going on in every corner of the organization.
Dan: When you have conversations with teams and with the products people as well, you need to kind of be able to quickly dive in into the different products. And you need to be able to quickly dive into these areas and ask people the right questions and [learn] what’s the business motivation for the product to do one thing or another and support one thing or another.
So I think that’s quality you need to develop or have in order to be able to work with a wide range of groups.
You know, my job title is kind of “APIs”. It’s to work on APIs. But you can’t have a conversation about APIs without understanding the underlying technologies that make them work.
It’s all connected. So you need to be able to talk about different technologies. Some of them maybe you’re more familiar with and some of them you need to get familiar with.
BUILDING THE PLATFORM
Finally, after all of their prep, they were ready to actually build something.
Itai: So the first thing we started doing is looking at how we want things to actually work.
Dan: The processes become more defined. This is something that we really worked hard on in the last years to define processes.
Itai: Building authorization and authentication systems which were standard inside of Wix and outside of Wix. The second thing was to try and define an API language.
Dan: So how do you create a new API? What’s the right process for it?
Itai: What we did is try to define a domain-driven based approach. Which meant that you had to explore each domain, define its main entities, start defining the APIs and start defining how everybody would use them looking not only at your immediate use cases, but also use cases that might come from outside the platform.
Dan: Once you have well-defined processes, then it’s also easier because you can always direct people to read the guidelines and the manuals.
SUCCESS/TAKEAWAYS
All kinds of talented, hard working people are necessary to make an organization thrive. But before Dan and Itai, Wix was a minivan with a tractor’s engine, bicycle wheels and a clown car horn. Every part worked well on its own, but didn’t agree together. It’s their work that brought all these disparate parts into harmony.
Wix still operates as many different, independent companies. These companies still have a great deal of autonomy and make their own rules. But now each can do so without clashing with the others. All because a couple of guys took the time to listen to them, understand their individual needs and come up with an agreeable solution rather than a forced rule.
Itai: We did start getting a lot of traction inside of Wix. Management started defining it as a must for people to have APIs. And it was something that was reviewed regularly in the meetings of the operations guild, to see which APIs were platformized, which weren't. And we were starting to see a lot of traction inside of the company to start making this a de facto decision for Wix engineering.
Nate: With your experience dealing with people, what lessons can you impart to those listening who aren’t in platformization but still of course have to deal with people at their jobs?
Dan: I can tell you a story from, actually, last week. We just concluded yesterday. So we had a very big engineering debate of some sort and different people had different opinions and pulled in different directions and it felt like going nowhere. And then we decided, OK, we need to have this process on how to resolve this.
So we defined the process. We said – we opened a spreadsheet, we said OK, these are the categories by which we are going to score the different options. So we created this scorecard and we had a weeklong debate in Slack about the pros and the cons of each option. A new option was born during the week and people argued and voted and at some point, my colleague tells me that he feels like it’s a – people just arguing just for the sake of argument, not because one thing is better than the other.
I told him, look, this guy for example, I know his scars. I know where he’s coming from. I know he’s really – didn’t sleep nights for weeks because of – it was dependencies. So because of that.
So everything he says, it has a reason. It’s not just because he’s arguing. And once you know that, you kind of realize where people are coming from and why they think the way they think.
It was a hard week but eventually we got to a decision and I think we – it ended up quite well because I think everyone was happy with the results even if it’s not what they thought. But because of the process, because it was transparent and because it was – we allowed everyone to speak up and give their opinions - and overall even if it’s kind of – took a lot of time - I think it creates more trust between different people and trust in our group specifically.
Nate: So Dan, to wrap things up here, how can other companies do their own versions of platformization better?
Dan: Right. So key to all of this to succeed is that the management will be the driving force. Management is used to asking people “what about this feature” and “what about this capability”. And in order to create a mind shift in people’s way of working and in their processes, they need to start asking different questions, they need to start asking “what about your APIs?”, “Who’s using your APIs?”, “What was the feedback from external developers that are using your APIs?”.
Another thing is basically all the technical infrastructure needed to support standards. So what we did was, on one hand, we created new standards. These could be simple things like new conventions and stuff like that, could be more complex things like how you do authentication, how you allow queries on your APIs. And in order to allow people to implement all of this you don’t want this to be repeating work. So you need to start building the infrastructure.
So in some places we had to create new groups or new teams that would support and create this infrastructure. And this is alongside the teams that are actually using it.
Nate: And what resources can you give your people, your developers, to help make their lives a little bit easier in all this?
Dan: We indeed write a lot of new guidelines and a lot of things that people have to follow. It’s hard to remember. And even if you do, it’s not always easy to follow, sometimes you’re missing some infrastructure, sometimes you have deadlines that you have to keep, so some things are on the enforcement side. You have to block people from releasing things if they are not according to guidelines. Obviously not on every little thing will you block someone because you do want to allow the business to move on, but some major things you will decide to or have to enforce. Right now, for example, we’re building some tools that will run during the CI process and they will be able to break builds if you’re not conforming to some of the guidelines.
Nate: Finally, from the business standpoint, not just the engineering standpoint, how do you persuade the decision makers at the company?
Dan: The products that are more mature in this sense. They started to see that they gain business value from it, so they have tens of applications, external developer applications that are actually using them in the app market, in Wix App Market. And they see the value for their customers and customers are now getting features that they would never get to develop themselves.
That’s it for this episode, thank you for listening. For a full list of our previous episodes - visit wix.engineering/podacst. The Wix Engineering Podcast is produced by PI Media - written by Nate Nelson, produced by Guy Bin Noun and narrated and edited by me, Ran Levi. Special thanks to Moard Stern from Wix. See you again next episode, bye bye.
For more engineering updates and insights:
Join our Telegram channel
Visit us on GitHub
Subscribe to our YouTube channel