Over the last few years, Luno has been scaling. Upgrading more customers to a better financial system has meant our engineering and product teams – more specifically, our build team – needed to adopt a structure that accommodated this growth. This article will explain how we did it.
Peas in a pod
We started with the concept of cross-functional teams, which we call pods. Pods are a data-driven product area within a fleet, mandated to make decisions in order to deliver the best product.
Pods comprise of a combination of product, engineering and design all working towards a common business objective.
Software engineers are grouped according to a specific competency. At Luno, the engineering team is divided into web, mobile and backend competencies. A pod could have engineers from all competencies or from one depending on the pod’s focus area.
The unique aspect of pods at Luno is that they work together with a product area. We have certain pods serving an area for our customers or business teams, that in turn aid our customers.
An example of this is pod-shield, who focus on customer security. This pod is responsible for aspects of security, such as OTPs (one time pins), authorisation and authentication. Another example is pod-payments, who work closely with our payments business team. They are both responsible for the day-to-day facilitation of transactions, integrations with payment providers and financial institutions.
Adapting for growth
For a while, pods were sufficient to meet Luno’s scaling demands. However, over the last year, we continued to scale and add more pods in certain product areas. This introduced some inefficiencies.
We started to ask these questions:
- How do pods work together to deliver in a particular product area?
- How do pod members collaborate to share knowledge and information?
- How do we ensure that there are unified objectives for that particular product area?
- How does line management for so many pods and competencies work?
We needed something else. Something that drove collaboration across Luno in a way that allowed focus on particular product areas. We started with a simple grouping of pods into these product areas. With this as our view, we started to think about how we could create a structure that ensures expansion along with our business units. Another consideration pertained to how leadership would evolve.
Fleets: The future
After some iteration and discussion, we introduced the concept of fleets. A fleet is a data-driven product area within Luno mandated across multiple pods and teams to make decisions that ensure the best product.
We introduced the following roles into the structure to ensure alignment across engineering, product, design and business:
Sponsors are accountable for the fleet’s overall objectives. They are primarily concerned with ensuring that the objectives are delivered to the agreed business benefits. They also serve as the representative of a product area within Luno, playing a vital leadership role throughout.
Previously, we had engineering manager roles that were based on competency and location as opposed to a specific product area. To make this more efficient, we reconfigured and now have engineering managers who look after fleets that span a variety of competencies.
The product manager focuses on the fleet’s long term vision. They define the product roadmap and assist in leading the fleet to achieve their goals.
Finally, we formalised roles for engineers into two parts: tech lead and principal engineer.
Tech Lead: An engineer in a fleet who’s responsible for driving engineering practices for a specific competency. Part of their responsibility includes ensuring that within their fleet and competency, all members adhere to Luno’s engineering standards. They also have ownership of tech documents and work towards improving the [build] architecture for that fleet.
Principal Engineer: An engineer who falls within the larger competency and is not part of any particular fleet. This engineer is accountable for the entire competency – either web, mobile (android/iOS) or backend. These principal engineers collaborate to ensure we’re implementing the best architecture for the Luno platform. They also focus on ensuring our platform scales effectively in order to meet our objectives.
Having a defined structure is imperative in order to successfully scale. This structure needs to support the onboarding of new team members who will have ownership over their respective product areas. In addition to this, a comprehensive structure assists in ensuring each member of a fleet or pod has clearly defined areas of responsibility and accountability. Ultimately, our structure needs to help us get to the moon, figuratively speaking.