Moving to cross-functional teams

Posted by Mircea Gheorghiu

Bit of history first

In early 2019 we embarked on our biggest engineering programme we’ve had in the last 2 years: re-platforming our originations systems. These systems are responsible for the entire loan application process which our borrowers go through. It orchestrates the whole flow: Eligibility Checks, Credit Risk Assessments, pulling Bureau Data from Third Parties and ultimately runs our Statistical Risk Models (which predict the likelihood of default and therefore how to price loans).

Needless to say, this was (and still is) BIG! We had to divert a significant part of our tech and product teams to tackle this. We had teething issues and challenges with finding the right approach to deal with such a big project and eventually we found our groove and managed to deliver our first big milestone by December 2019.

title

What are cross-functional teams for us and why are we doing it?

While this was a massive success, 2020 will be even more challenging as we want to accelerate this re-platforming and be even more ambitious with our agility and ability to deliver quicker. One of the issues we have observed last year was that the engineering teams involved in the project were built around specific components of our platform (e.g. we had one team doing the front end of the application, one team building an API, 2 teams working on data connectors and back-end systems, Salesforce engineers dealing with different requests as a single team) and while we did achieve our objectives for the year we felt that there was too much handover between the teams and dependencies that slowed us down at times.

So while planning the 2020 roadmap and the team allocations we decided to mix things up and create teams that will be able to build fully functional vertical features across our whole technical and business stack. We’ve come up with 6 brand new teams that have the necessary skills to tackle any problem thrown their way, be it front end, back-end, stream processing or Salesforce. Teams even came up with new names for them, although they did keep the theme of being named after animals: Spice Gulls, Wild Barcodes (basically a fancy name for Zebras), Zealous Zebras (what is this obsession with Zebras??), Flaming Puffins, Tenacious Dragons and Crimson Camels. We’ve intentionally left out any data or DevOps/platform capabilities outside these teams as we want to start this concept and iterate over it before we embrace fully cross-functional teams.

Of course, cross-functional teams are not a silver bullet, they will help us solve some of our inefficiencies but they will introduce some challenges along the way as well. Here are some things we already know might be hard:

  • While the teams might be cross-functional and able to tackle problems in React, Ruby, Clojure, Kafka or Salesforce (yup, that’s pretty much our tech stack right now), most of our engineers are not cross-functional or T-shaped as we like them to be called. So there will be a big focus in the next period to ramp up people to be able to move towards that T-shape engineer that we would like to have. That will come with implications in terms of delivery times as well as career development (our career growth framework will need some adjustments for sure).
  • With all 6 teams able to build features on any part of our platform, the code ownership becomes distributed, with no core team maintaining any particular component. This could prove challenging in terms of keeping the architecture vision and integrity of individual components. To counter that, we’ve created Chapters (no, we’re not trying the Spotify model, it’s very loosely based on that), which are groups of engineers maintaining, enhancing and supporting certain well-defined components of our platform (including code ownership for said components). I’ll expand on that in future posts, as I do feel that’s a whole topic on itself.

It’s early days of this experiment, the teams have just completed their first iteration and they’re halfway through the second one but signs look pretty positive: everyone feels genuinely excited and there’s a good buzz around the engineering floor. The work completed in the first 2 weeks surpassed our expectations as well so well done to all the teams involved!!

What’s next for us? Well, we will keep focusing on getting Chapters up and running properly, iterate over our process of dealing with tech work (another pain points of ours in the past) as well as starting sending surveys to the teams to gauge their engagement and happiness but also get some early feedback about the changes we’ve introduced. Stay tuned…


Thank you for reading! Make sure to follow us on Twitter and Medium.