Squads, tribes and the rise of a new startup
I have just started in a brand new company, a startup that aims to change the way insurance is sold in Brazil. Insurance tends to be a rather boring subject, where companies patronise people as if they need one more giant entity telling them what and how to do things. But we are in the mobile era, and Spotify and Nubank are just two examples of a large, exciting change that is happening under our noses.
Uber has been struggling to be allowed to run while TV channels are fighting to the end to make Netflix pay even more taxes. It seems easier to hit the competitors instead of improving its own business model, it seems. The man in the middle does not want to lose his share. It is a matter of time, though. There is no reason one should pay 90% of the income from his/her book to a publisher that will do nothing except putting the book in an online store that no one access anymore. Amazon KDP came to stay.
The future is going to be different and I am glad to give my small contribution to make it happen. Things do not need to be intrusive, expensive or boring. Why not give control to people? We don’t need someone telling us how our insurances must be as much as we don’t need an account manager to feel safe with our credit cards. Not anymore.
The climate is amazing in a startup. We are involved in everything, and by it I really mean every single thing, from sketching lines in a paper trying to figure out how the website navigation will flow up to interview new candidates. Cool. There is so much to do that I need to arrange my time in a way I never needed before, and every day I learn so much that it is hard to process such a load of new information.
But not everything is a bed of roses. Because we are starting everything from scratch and there is nothing defined yet, we can try to do things in the way we always felt was the best. We are defining things, but we are doing it at the same time other people are doing it, but in a different, conflicting way, and the team size increases in a speed that is hard to keep track. Communication is not flawless and the scary deadlines are haunting us from every corner.
In Youse, we adopted the model that worked beautifully well on Spotify, with squads and a whole lot of scrum going on behind the scenes. We are starting with three products and a user profile area, which means we have four squads at full speed working hard to make the dream come true. An agile coach is on alert to make sure the methodology is working as expected, and a huge amount of autonomy was placed on to make things happen.
Because nothing is really well defined, we, as developers, have been doing a lot of rework. Pages are being redesigned many times in a row and we are almost blind to what the other squads are up to, because no matter how much we try to stay tuned by doing code reviews and sync meetings, the products are growing at a fast pace and changes that seem small are really painful, they affect everybody. We decided to use the same code base to avoid duplication of code for now, but the drawback is as hard as trying to move the squads apart.
Up to now, there are a few tips I can give to those who are considering to dive into a startup like we did. The design and UX of the products must be coherent and standardised, which implies it is a very good idea to start by creating a style guide that will grant every product will follow in the same direction. It does not matter how cool the idea of a page might be, if it does not follow the style guide it will just move everyone out of the desired path, forcing the squads to redesign a whole lot of things. Avoid rework.
Another time-consuming issue is that every new User Story comes with a “do as the other squad did”, although there is a “tiny small change here and there” that makes it impossible to reuse what was previously done. Things like “I want that same select box, but with a search bar at the top and opening in another direction”. Build base components at the very beginning, before jumping head first into the wild world of front-end. A new improvement in a component must be automatically usable on all other products without forcing them to rebuild anything (or, if changes are inevitable, make them be small and quick instead of colossal and scary).
Rushing to deliver the sprint deadline at the cost of making the next squad having to decouple everything later is a recipe for a failure, and if one squad fails the whole company will fail.
Give a lot of thought to how to make an efficient and ubiquitous communication, without it all squads are doomed. Choose your tools wisely and try things up, and if one or another does not work don’t be too worried about the time you lost with it, think first of how much time you will save by moving on to another better solution or idea.