Recognizing the Problem
As a growing startup, Lusha is no different than any other hyper-growth company in its R&D goals .
The pressure is on to produce great results.
But sometimes the environment you’re operating in works against you. Not intentionally of course, but having an inefficient team structure can hurt the efforts of the entire team and hinder your road to timely production.
The good news is that if you catch it early on, you can make the necessary changes without losing momentum. For us, that realization came fairly early in the company’s growth. Problems were accumulating and we were forced to break down our cycle to see what we were really dealing with.
This is what we found:
- Too many dependencies between teams within R&D – it’s difficult to work when everything you do depends on other teams.
- Misalignment between R&D and Product Managers – without great communication and agreed-upon expectations, you can’t expect Dev projects to sync up with the overall strategy of the company and work in tandem with other teams.
- The dependencies and misalignment lead to an overwhelming amount of bureaucracy.
- Our developers felt a lack of ownership over the processes they were working on, feeling they were not hand-holding the projects from inception to deployment to production.
Finding a solution
What did we do you ask? How did we tackle what was obviously not working and switched to an efficiency model? We implemented a ‘divide and conquer’ strategy.
First, we joined forces with the Product department and other departments in the company. Once we were merged, we split up our R&D and Product workers into smaller units which we called ‘squads’. Our squads would jointly own specific projects, working collaboratively and independently from other squads, and owning their projects from e2e.
The squads encapsulated workers from different backgrounds which brought to the table different sets of expertise. Together they created sorts of self-contained ‘mini-startup’.
By giving each squad ownership of a project, each individual employee felt more connected to their work and became more driven to perform. Additionally, e2e ownership of their projects, allowed our developers to learn different aspects of the development process and see more clearly how they make an impact.
But before you go creating siloed squads that work independently, make sure you don’t completely eliminate interdepartmental communication and communication between the different squads. This type of cross-departmental, cross-team communication is still the overarching strategy that guides the ship, and it must trickle down to the individual squads from the communication and ongoing collaboration between team leaders and in the higher ranks of the company.
The Squad as a Stand-Alone Unit
We created 8 squads which we divided between three group leaders (myself being one of them).
While there are slight differences between them, an average squad would look something like this:
- Team leader
- 3 Developers
- QA
- Product manager
- Graphic designer
- Business analyst
We aimed to create a self-contained ecosystem for each squad that would allow it to quickly and efficiently tackle most day-to-day activities and have the resources to develop quality products in a timely fashion.
The Results
The change we implemented proved successful on several metrics:
- Massive reduction in bureaucracy and finally streamlined work processes
- An increased sense of ownership and overall employee satisfaction
- Increased connections and interpersonal relationships were born out of our diversified squads which would have likely not happened had these workers not been pulled in to work together
- Quicker onboarding process for new employees
- Increased transparency for team leaders and higher management over the processes undergone by each squad
But Wait, Squads May Not Be for Everyone
While this strategy change worked well for us, the squad approach isn’t for everyone. The main reason being lack of resources.
As long as the company is small and focuses on a few projects, there’s no reason to split your resources between several teams. You’d much rather have everyone on the team under the same management structure and have full control over allocation of resources.
This becomes more difficult as time goes and companies grow and mature.
There is a certain tipping point which, when reached, means you’re expected to bring better results in less time. A requirement which forces companies to stop centralizing power and start delegating responsibilities, resources and ownership among multiple projects headed by multiple team leaders.
Creating squads too soon could actually slow you down rather than facilitate your growth. Be warned!
