The pressure is on to produce great results.<\/span><\/p>\n 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.<\/span><\/p>\n The good news\u00a0 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\u2019s growth. Problems were accumulating and we were forced to break down our cycle to see what we were really dealing with.\u00a0<\/span><\/p>\n This is what we found:<\/span><\/p>\n 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.<\/span><\/p>\n 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.<\/span><\/p>\n 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’.<\/span><\/p>\n 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.<\/span><\/p>\n 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.<\/span><\/p>\n We created 8 squads which we divided between three group leaders (myself being one of them).<\/span><\/p>\n While there are slight differences between them, an average squad would look something like this:<\/span><\/p>\n 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.\u00a0<\/span><\/p>\n The change we implemented proved successful on several metrics:<\/span><\/p>\n While this strategy change worked well for us, the squad approach isn\u2019t for everyone. The main reason being lack of resources.<\/span><\/p>\n As long as the company is small and focuses on a few projects, there\u2019s no reason to split your resources between several teams. You\u2019d much rather have everyone on the team under the same management structure and have full control over allocation of resources.<\/span><\/p>\n This becomes more difficult as time goes and companies grow and mature.\u00a0<\/span><\/p>\n 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.<\/span><\/p>\n Creating squads too soon could actually slow you down rather than facilitate your growth. Be warned!<\/span><\/p>\n \u00a0<\/span><\/p>\n <\/p>\n","protected":false},"excerpt":{"rendered":" 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 […]<\/p>\n","protected":false},"author":48,"featured_media":13446,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[117],"tags":[],"class_list":["post-13369","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-rd-management"],"acf":[],"yoast_head":"\n\n
Finding a solution<\/b><\/h2>\n
The Squad as a Stand-Alone Unit<\/b><\/h2>\n
\n
![\"\"](\"https:\/\/engineering.lusha.com\/wp-content\/uploads\/2021\/07\/Frame-518.png\")
<\/p>\nThe Results<\/span><\/h2>\n
\n
![\"\"](\"https:\/\/engineering.lusha.com\/wp-content\/uploads\/2021\/07\/Frame-519.png\")
<\/p>\nBut Wait, Squads May Not Be for Everyone<\/span><\/h2>\n