Navigating complexity: Collaborative insights from Zenjob’s open marketplace project
By Sneha Jagtap and Ana Suarez
In the dynamic world of tech and innovation, every project presents a unique set of challenges and opportunities. In this blog post, we dive into a remarkable journey undertaken by two teams at Zenjob — the Staffing and Job Discovery teams. Their collaboration gave birth to a transformative project, Open Marketplace — job discovery and staffing, which laid the engineering groundwork for Zenjob’s shift into a marketplace product. This post is a reflection on the experience we had, the lessons we learned, and the conclusions we drew from this significant achievement.
The evolution of an idea
Change is the only constant in the world of technology, and this project was the implementation of a fundamental change to Zenjob’s marketplace: transforming how jobs are discovered and staffed.
How did our core product work before?
Before getting into more details, it’s important to understand the core of the Zenjob product, which offers jobs to Talents in a feed and staffs the jobs with the most suitable candidate.
Talents — which is how we refer to our app users — come to our app to find work. Previously, when they opened the app, they could see a feed of available jobs, in various categories, based on multiple filter criteria. This filter criteria displayed each job to the best 40 Talents. The rest of the Talents couldn’t see all the jobs immediately, and it would be 30 minutes before the same process ran again. Once that happened, they may or may not have been able to see these jobs. This was so strict and specific that it prevented many jobs from being visible immediately in the feed for all eligible Talents.
Additionally, after one or more Talents applied for a job, our staffing system selected them on a first-come first-serve basis.
As a result, we were filtering out applications in an early stage of the process.
What were we about to change?
Zenjob wanted to change this marketplace behavior of how Talents were discovering jobs on the platform and how those jobs were staffed. This was not only to improve the user experience for Talents on our app finding jobs, but also to improve the time and quality of staffing the jobs.
With the new proposed solution, Talents could see more available jobs, and any job a Talent was eligible to work for would be made immediately visible in their feed. This, in turn, would enable larger exposure of jobs, leading to a higher number of applicants. Only later in the process, after several Talents applied for a job, would the most suitable Talent be selected.
This would essentially move the filter from the early stage of job feed to a later stage of staffing.
This idea had been simmering for quite some time, but it also challenged the current mindset and meant there would be a significant shift in our marketplace vision, so we had to wait for the proper alignment of business, product, and engineering priorities before we could take it on. Eventually, the priorities and focus aligned, providing us with the opportunity to invest time and effort into making our vision a reality.
Why was this project different?
The marketplace project at Zenjob wasn’t a typical project. It stood out primarily due to several distinctive aspects and challenges. Below we outline the most important of them.
Architectural transformation
The new product vision involved increasing the amount of jobs exposed to Talents. This would mean more jobs visible and more applications from Talents, which translates into a higher volume of data and transactions on the platform.
However, the legacy architecture couldn’t scale gracefully under the new expected load. Some foreseeable problems could have been substantial delays in showing jobs in the feed and booking them, potential generation of inconsistent data, and the risk of having an unresponsive system during high season.
There was a clear need for a significant architectural transformation of our core systems.
Teams and domains
The new marketplace model mainly targeted two of our domains: discovery and staffing. The existing group structure in the marketplace consisted of several teams, with two of them responsible for covering these two domains, but in an independent manner. To deliver the project successfully, we needed them to join forces and work together. This brought up the question of how to best do this.
Knowledge silos
As mentioned above, we had two teams — one for each of the two domains. However, those teams were formed not long after a company restructuring, and the knowledge and expertise of each domain weren’t evenly spread among the teams. Instead, it was isolated to specific individuals, creating knowledge silos. This limited effective delivery and a widespread understanding of our vision on how to evolve the core systems. To address this issue, we worked to empower our fellow engineers across the marketplace group, which spanned these two teams, by encouraging active engagement, learning, and mutual support.
The next section will go into more detail about how all these challenges were addressed by adopting specific ways of working.
Adopted ways of working
In the section above, we described the unique challenges of the project that we had to overcome to make it a success. Our commitment to turning this vision into a reality and breaking down silos to foster collaboration made this project a unique and transformative journey — not just in the project itself, but in the working methods.
Emergence of a working group
Recognizing the critical knowledge gaps and the silos existing within the two domains, a collaborative working group emerged. Engineers and Engineering Managers (EMs) from both teams joined forces, alongside Product Managers, to merge under a shared initiative. The new working group combined all the everyday ceremonies as if it were a single team: one single sprint, and joint technical refinements, estimations, and planning. Progress was demoed and status was communicated as one single unit. We were testing, launching, and celebrating as one team. This created a space for knowledge sharing and helped us overcome the preexisting knowledge silos.
Pragmatic delivery
Due to the nature of the project, which was both long-running and required an architectural change, it was crucial to implement a structured framework with clear checkpoints and a rapid iteration process. This strategy ensured we could effectively introduce the new architecture without any disruptions and adapt to the evolving complexities of the project as it progressed over time. The approach consisted of the aspects outlined below.
Validation through POCs
Before diving into the deep end, the teams validated their hypotheses through small Proofs of Concept (POCs) on both the Job Discovery and Staffing sides.
Incremental delivery
Breaking the project down into clear milestones was instrumental. It allowed us to separate the work into manageable and achievable pieces. This approach ensured steady progress and enabled us to deliver the new architecture in a continuous way, getting early feedback, thus minimizing the risks.
Detailed planning and timelines
We thoroughly refined our project plans for each milestone, working together as a team to establish precise timelines. These interactive sessions allowed us to craft a delivery roadmap that was not only comprehensive but also realistic.
Shared goals
Across the board, we maintained clear and common objectives. These goals weren’t just confined to the Product and Engineering teams; they also extended to our business stakeholders. Aligning and prioritizing this on everyone’s roadmaps ensured the working group was focused on one single topic and not derailed by other topics. In turn, this enabled everyone to move in the same direction, which fostered cohesion and collaboration.
Centralized communication
We followed the standard company practice of using a dedicated Slack working group channel for collaboration. This channel extended across the Product and Engineering department and stakeholders for seamless cross-functional teamwork. Having a centralized channel for project discussions and questions helped everyone be aligned and focused on the shared common goal of the project.
The transformative effects
The adopted ways of working helped in the successful delivery of the project. But there was more to it: The additional bonus was that it enabled the teams in the marketplace group to grow in a number of ways.
Knowledge empowerment
The collaborative model facilitated the spread of domain knowledge, enabling a wider group of engineers to engage, learn, and contribute. This also encouraged the learning and development of good engineering practices — like detailed milestones, roll-out and roll-back planning, and detailed tracking and monitoring strategy across the teams. It not only ensured the sustained operation of the project and further maintenance of it, but it also set the teams up for success for future initiatives in these domains.
Enhanced capacity
The joint effort generated an increase in availability and capacity. Every engineer across the two teams gained a deep understanding of the goal, target architecture, and core systems, which enabled continuity even when capacity and availability were low.
Improved working dynamics of the group
The teams evolved their collaborative mindset to the next level, crossing the limits of our traditional domain-driven teams and enabling individuals to have a wider vision and empowerment to drive change that impacted both areas. As a result, the working dynamics of our marketplace group improved.
Timely delivery
With this approach, we managed to deliver all the milestones of the project on time, irrespective of its huge scope and complexities.
The hidden price we paid
As is the case with everything in life, nothing comes for free, and there was also a price to pay for this new way of working. However, we faced these overheads with an open mindset, made some compromises, and aligned to find the best direction to take us to success. Below are some of the things we encountered on our journey.
Management overhead
Balancing the expectations and priorities of different teams required diligent management and communication, particularly for Engineering Managers (EMs). As the working group consisted of members across two different teams, managing the work and tasks was a challenge until we moved all the work of the working group under the same hood.
Clarifying roles
Defining clear points of contact for vital roles such as EMs, Product Managers, and even engineers required continuous discussions and agreements.
Alignment struggles
Navigating alignment across various levels — engineering, management, the data team, product, and stakeholders — demanded a conscious collective effort for the roadmap and status alignment.
Conclusion
Is this approach a silver bullet? Well, it’s not a one-size-fits-all solution. Its effectiveness greatly depends on a specific project’s characteristics and challenges. In our case, the collaborative working group proved to be a perfect fit due to the project’s unique complexities, such as its extensive scope and the presence of substantial knowledge silos.
However, it’s important to note that this approach may not be suitable for all projects. The challenges, particularly in terms of management and communication overhead, can outweigh the benefits in simpler and more routine agile projects. For these routine types of projects, it could be more efficient to handle everything within a single team rather than creating a separate working group spanning different teams.
So there are tradeoffs, and if you plan to take on a project of similar scope, we advise you to choose wisely. The key is to adapt the approach to the specific needs and demands of each project, striking the right balance between collaboration and efficiency.
