When people learn about our way of working at SadaPay, they sometimes tell us it won’t work “at scale”. At scale – they say – we will need estimation. Deadlines, sprints, detailed road maps, project managers, engineering managers and so on.

But what do they mean by “at scale”? They’re not talking about the number of customers we have, or the impact we have on people’s lives. They’re talking about headcount. But the challenges people face in larger businesses are not due to headcount – or scale – alone. They are side-effects of the way their organisations have scaled – the way they’ve changed their structure to support more people doing more work.

‍

More People, More Problems

As companies grow, they make many seemingly obvious choices that have negative implications they don’t yet understand. Hiring somebody new? Add them to an existing team. Have more capacity in an existing team? Start some extra work. Having trouble keeping all that work on the rails? Add process. Having trouble managing your processes? Hire another manager. Each decision makes sense in the moment but before you know it, your culture and organisational design have shifted radically. Suddenly you’re not a fast-moving, disruptive start-up anymore – you’re more like the big, slow companies you were in the middle of disrupting.

It’s a common pattern. Larger teams have higher work-in-progress, which requires more process. Defining and enforcing more process requires more managers, who in turn need their own processes and managers. Eventually the ratio of productive team members to managers becomes so low and the amount and complexity of processes so high that team member autonomy is undermined. The team becomes top-heavy and inefficient, its members disempowered and micromanaged. Some people call this “growing up” and perhaps it is, as growing up is involuntary – an automatic process. As SadaPay scales, we want to do better. We are being proactive and thinking carefully about how to scale without giving up what makes us effective.

‍

Optimising for Autonomy

We divide the Product Engineering Team into small squads that operate with high autonomy. As our headcount increases, we swell and split existing squads to create new ones. We do a lot of work to make sure that squads are small, because small squads only do one or two things at a time. That means they can be low-process and in turn, low-management. In this way, a small squad provides high autonomy for its members. But it creates another challenge – if we aren’t careful, our squads may be so small that they lack the capabilities they need to work independently. That would create external dependencies, chained backlogs and even deadlocks.

So we arrive at a fundamental tension. Smaller squads provide greater autonomy to their members, but the squad itself may have less autonomy within the Product Engineering Team. They are more likely to lack some essential capability that becomes an external dependency. On the other hand, larger squads provide less autonomy to their members (because they need more process to manage high work-in-progress), but the squad has more autonomy within the organisation (because it is less dependent on external teams). To navigate this tension, we try to look past obvious choices and think on a longer time horizon. Our approach is threefold.

‍

Vertical Squads

First, we optimise for squad autonomy by making our squads vertical. They are oriented around areas of value for our business and have the capability to deliver value independently. For example, Cards Squad is responsible for card issuing including everything from ordering, printing, shipping, labelling, delivery and activation across all platforms. We don’t have separate teams for things like front-end or back-end, because such teams would not be able to deliver value independently and could never operate with high autonomy.

‍

Versatile Squad Members

Second, we use learning to add capabilities to a squad without increasing its headcount. This goes naturally with our engineering practices and high-collaboration way of working. The more we can learn, the less we have to depend on people outside the squad for specialised skills and the more autonomous our squad can be.

‍

Tribes

Third, we accept that squads with low maximum sizes (4-6 people including all roles) cannot have every capability. Capabilities we can’t fit into a squad are extracted to a layer close enough to have shared context and goals – a tribe. Our tribes will act as local hubs, providing common capabilities to their squads. We’re just starting to build our first tribe now.

‍

Try it!

Balancing size and capability – individual autonomy within a squad and squad autonomy within the organisation – has been a critical part of SadaPay’s growth. It’s how we’ve built 8 squads that each have the same energy and collaboration of a first year start-up. It doesn’t just work at scale, it’s how we scale – while making sure SadaPay is still an empowering place to work.

If your team is slowed down by missing capabilities, maybe you can import them by learning or changing members so you don’t need as much help from outside? On the other hand, if your team is slowed down by complex processes, maybe you can shrink a little and reduce work-in-progress so you don’t need as much management?

If you’re interested in working somewhere that believes we can make an impact at scale without sacrificing our autonomy, reach out to us!