Working at Lusha is never boring. Lusha offers a fun environment and a select group of great people and outstanding professionals, and, by the way, it’s a company that also happens to be going through hyper growth.
I Joined Lusha in the mid 2020, when the company was about 4 and had roughly 80 employees out of which 20-25 were in R&D. Today, just over a year since I joined, Lusha employs over 200 workers,+70 of which man the different R&D teams, and our customer base and revenue have more than doubled in this period of time too.
When companies enter hyper growth phases, they often find that what had worked well to get them from point A to point B, is no longer enough to get them from point B to point C. Growth and scale require transformative processes to infiltrate at all levels, including to the existing methodologies and company structure.
After I joined we went through an organizational change which we named it Delivery 2.0.
At the time we already had teams structured as squads(including PM, Designer, analyst, developers and QA) trying to make these teams more mission focused and autonomous. We had a flat structure of 5 squads, some of them had too many responsibilities so they couldn’t achieve their goals properly. We decided to split them into more granular and focused squads in order to allow the organization to manage its resources more efficiently and increase velocity. We created a group structure that is responsible for several squads sharing the same domain and business area.
Today we already have 4-5 squads in each group and need to plan the next phase – Delivery 3.0, designed to solve some of the growing pains we are facing today.
Once I was tasked with scaling our engineering team by 200-300 workers in the next couple of years and set about to look for viable solutions to this challenge, I came across a fantastic read titled Team Topologies by Matthew Skelton and Manuel Pais, which I highly recommend making the time for if this is your line of work.
I’d like to share here some insights gleaned from this book as they apply to my previous experience of growing Engineering organizations, and I’d like to share too how I applied those to my latest challenge of (hyper) growing my Lusha team.
Conway’s Law
Conway’s Law (1967) is one of the organizing principles of delivery based companies. Simply put, this law relays the idea that the systems (broadly defined) that organizations build take after the organizations’ communication structures.
This was proven to be correct for different kinds of software architecture like Monolith, SOA and Microservices.
We could use the power of this phenomenon to impose specific structures and communication lines in order to lead to a desired architecture. To do that we would have to apply reverse engineering on Conway’s Law, so that when executing an architectural design we will need to adapt our communication lines and structure to mirror that design.
The Human Factor
This is all good and well, insightful and to some degree applicable too. But it fails to take into account the ‘human factor’.
When thinking about teams and structures, we have to take into account our workers’ cognitive load.
Our employees need to know and remember many things in order to perform their tasks. From different programming languages and databases to working on a specific cloud environment. They need to remember how to deploy, how to test, OWASP top 10 and many other things. Last but not least, they need to have specific domain expertise so that they can do their job really well.
As managers, we should always try to maximize the domain expertise and make that their top priority and focus. All the rest of the load should be minimized and be supported by tools and platforms we provide that could automate things and free their mind to the most important things.
Teams are not really “one size fits all”. There are a few kinds of teams, the type that takes upon a mission and has a constant flow of tasks and requirements that pushes that mission’s goals forward. The team that builds platforms to help reduce that cognitive load explained above by automating things and reducing friction. Enabling teams that can jump in and assist by reducing complexity and taking some stuff off their plate ad hoc and minimizing the context switch or need to explore and learn things that are not their core capabilities and so on.
We should try to maximize the amount of teams that are mission oriented and have a constant flow of work and make sure we have the supporting ecosystem of platforms and enabling teams to allow them to run fast and achieve the company’s main goals.
Every type of team has expected behaviours and should practice different communication patterns in order to make them work effectively together and reduce dependencies and friction.
In some cases teams work in collaboration with other teams, sometimes a team provides something as a service to others while in other cases a team can facilitate other teams to join them in an effort to reduce obstacles.
Bottom line
To summarise, while every organization faces different challenges as it matures and evolves, the philosophy behind ownership creation, mastery and autonomy within teams and the shifts of organizational structures to accommodate these, remains the same. Our job as R&D and Delivery managers is to support the business needs by providing the right structure, process and technology to execute and deliver in the expected velocity, quality and agility. This is never a one off task, this challenge is dynamic and constantly evolves as the business does and our job is to stay alert, anticipate the coming challenges and always be open for feedback and for change.
