When you're building a product from scratch, there will be some kinks and changes as the product and your team scale. Yonis Abdillahi is an Engineering Team Lead at Wrk with more than 5 years of experience in the software engineering space. Here are his thoughts on Wrk's engineering transformation. He observes from the time he first joined in 2020 to now as we move towards product-led growth with the launch of our Self-Serve Platform!
I’ve always been a very analytical person looking to solve problems, so naturally, I became a software engineer. My career path eventually led me to Wrk in July 2020. The 'work' they are looking to optimize is a general and wide-scale term, and for a company with such an ambitious vision to cultivate and change the way people work— that’s what drew me in.
Internally, as a team, we all know how big this is and how it’s our responsibility to make this vision a reality. It’s fun and challenging, but also very rewarding. As our Automation Platform and team have scaled, there have unsurprisingly been a lot of changes and mindset shifts. And as we’re pushing toward product-led growth and general availability with our Self-Serve Platform, it’s important to remember where we started and how we’ve worked up to this moment.
Initial engineering organizational structure
When I first joined Wrk, our team was very small. As with any new business, our main goal was to build and test our minimum viable product (MVP) to make automation easier. We were looking to scratch the surface and gain momentum in the marketplace. Early on, we focused on building out our core features. As we started building, we faced challenges because our product was so broad and we needed a logical division.
We split up the engineering team into different areas of our product and ownership. This allowed our teams to individually focus on the different areas of our product.
For example, we had our Wrk Platform (or Client-Facing) team which focussed on what our clients would be using to build their Wrkflows as well as how they would be building and launching them, and how data would be populated from the Wrkflows. In terms of scalability, architecture, design, and robustness, our engine piece required different sets of skills and levels of focus. So we developed what I call the “heart of Wrk,” the Engine (or Core) team. We also had the Automation team which built our bots (or Wrk Actions) that would be the building blocks of our Automation Platform. Finally, we had a team to manage the human element of our Platform, as our system is a Hybrid Automation model, with processes executed by both machines and humans. This is what distinguishes Wrk.
With our teams sprinting in different directions, we were able to focus effectively on rounding out our core features, improving our security and infrastructure, and understanding our customer journey.
Our original silos allowed us to build the different parts of our Platform in isolation and enabled teams to iterate and build features quickly. Then, to push towards launching, we had to make some changes to enable Wrk to be where it is today.
https://youtu.be/q5-cwfs8MPU Check out our video as Yonis breaks down how our Engineering has transformed to help push us towards product-led growth.
Engineering transformation with internal communication
Our separate Engineering teams united on a common goal to release Our Platform to the public and push towards a product-led growth model (PLG). To do so, it became necessary to break down the silos.
We did this by piggybacking off of Wrk’s overarching theme of overcommunication. Wrk tries to keep a flat organization so everyone on the team can access the same information. We do this mostly with weekly all-hands meetings, which provide an overview of every department, from sales and marketing to operations and finance, and use technology to stay connected even though we all work remotely. And we knew that our Engineering team would have to change our communication structure to push toward PLG and unify our language as a group.
We evolved into cross-functional teams and invested in an internal Wiki to shift from tribal knowledge to documented knowledge. This allowed us to understand how different parts of our system work together and develop our unified language. Now, for example, everyone across our company can understand what Wrk Actions are: individual pre-configured units of work that you can drag and drop on our Wrkflow Designer to create your own automated processes.
By making sure we’re all speaking the same language, we can truly understand how each piece of the puzzle contributes to value for our customers.
Releasing our product with the PLG method
Once we refocused our efforts on aligning our teams on one mission and emphasizing communication, it was time to officially release our product to the public, which we did just over a month ago now! Users on our Platform will help us drive our roadmap as we advance by providing us with valuable feedback. In the process, we will also achieve our goal of making our customers quantifiably better by prioritizing their needs.
Now that Wrk is officially out in the wild, we’re very excited about what’s coming down the pipeline next. Over the next year, our primary goal is growth. And ultimately, across the board, we are focused on redefining work with simply powerful process automation that our customers can access with the click of a button. We want our customers to experience that “aha moment” of discovering a new and improved way of getting their work done.
If you want to unlock some of this power yourself, book a demo with one of our experts today!
