uSwitch is a price comparison website that helps customers find the best deals on energy, broadband, insurance and more. Each of the products we compare is unique and operates against different market constraints. As such each of them has a dedicated, self-contained team working on delivering the best experience for the customers and partners. The teams have a large degree of freedom to organise themselves, so while there are a lot of similarities in how different teams operate, they are not the same. The differences can stem from the size and maturity of the vertical, the different ways we integrate with the end providers, regulations and finally the specific experiences and preferences of the team members. This particular post concentrates on the insurance team where I’m working at the moment.
Insurance is one of the smallest products in uSwitch, with seven people working on it: a marketing person, a content person, an operations person, a commercial person and three engineering people. There is also one SEO person shared with another team and ideally, we’d have another front-end engineer working with us (yes, we’re hiring!).
Our main product is car insurance and it’s the only one we develop in-house. We also provide a few other types of insurance through uSwitch-labelled third parties. We sit together in one area and collaborate closely all the time. Whenever you have a question the person you need is sitting just beside you and on multiple occasions, you tend to overhear interesting information from people talking around you.
We set the direction of our work via the Objectives and Key Results (OKRs) approach, with some of the objectives coming from the company-wide initiatives while the rest are set by the team. We share one external email account per product, through which all external partner communication happens, and we have insight into the budgetary targets that we’re working towards. In a way, we operate like a startup but with the stability, benefits and support of a much larger, profitable business.
As a developer, I have both more freedom and more responsibility than in a traditional company. As you might have noticed there are no QAs, BAs or PMs in our team and all those roles are to a degree performed by developers. Engineers become experts in the insurance domain and gain an in-depth understanding of the product. As an engineer you’re expected to own the product and come up with the — not always technical —solutions to the problems.
We like data-driven decisions — a client-facing change in a product would often be A/B tested to validate our hypothesis before the launch. Developers have full access to production environments and are responsible for running the systems on the underlying infrastructure, which these days often means Kubernetes running on top of AWS with a service mesh in sight. We make sure that each developer can deploy directly to all environments quickly and we try to make new starters deploy at least one of their changes to production on their first day.
Given the developers are deeply embedded in the business context they can often prioritise the work themselves. They also make the decisions on how to approach quality and risk in the project. In some cases that might mean carefully testing a business-critical piece of code. More often though we go test-light or test-less and instead depend on extensive monitoring, both on software and business levels, to make sure that the site is both working for the customers and earning us money. In the context of page reliability as long as we’re earning money nothing else matters, and as long as we’re not earning money nothing else matters.
One of the nice consequences of having multiple teams working in an often similar problem space is the culture of stealing solutions from each other. In insurance one of our key results this quarter is implementing a tracking pixel for completed purchases on our partners' sites. That will allow us to get quicker and more accurate feedback on the product changes we implement. I know that quite recently the broadband team implemented a system that is very likely to meet our requirements. Guess what will likely happen! Eventually, if the problem is shared across multiple teams we might decide to provide a company-wide solution. Recent examples include integrating with affiliate networks and working towards a common A/B testing platform.
Our company setup means that new technologies and approaches can be first tested by a single team and, if the results are promising, implemented by more teams. Such an approach allows us to experiment and explore while limiting risk and initial investment. For the core parts of the systems, we would usually choose conservative, well-known technologies that we’re most comfortable with like Clojure, Rails or React. And we start introducing new technologies in smaller, less business-critical systems or tools.
Essentially, the core factors that we try to maximise in our environment are autonomy, mastery and purpose, as presented in the book Drive: The Surprising Truth About What Motivates Us by Daniel Pink. His theory is that being able to direct your actions, continually improving your skills and meaningful goals increases performance and satisfaction. I tend to agree.