For a while, being a small design team felt like a strength. Everyone knew what everyone was working on. We were fast. We were flexible. And then we started growing, and I realised we had been confusing proximity for structure.
There was a phase at SatSure when I knew what almost everyone on the design team was working on. Not because we had a sophisticated planning system. There were just a few of us. If a PM needed something, we figured it out. If engineering had a question, someone jumped in. If a customer needed a change, we worked it through. If something needed research, we researched it. If something needed a demo, we made the demo.
It was messy. But it was fast. And for a while, I thought that flexibility was one of the genuine strengths of a small design team. Being close enough to everything that you could move wherever the problem was.
What Growth Revealed
Then the company started growing. More PMs joined. We started exploring more industries, more use cases, more products being worked on simultaneously. And suddenly the same flexibility that had made us fast started creating a different problem.
Designers were switching contexts constantly. Picking things up because they had bandwidth, not necessarily because they were the right person to own them. A PM might work with one designer on one problem and a different designer on something completely different the following week.
And I started noticing something that took a while to name: people were spending time rebuilding context that someone else on the team already had.
One designer had spent weeks understanding a particular client's workflow, the language they used, the constraints of their process, the history of decisions that had led to the current product state. And then, for reasons of availability, a different designer was pulled onto the same product. And they started from zero. Asking the same questions. Making the same mistakes. Taking the same time to understand things that had already been understood.
The team was not getting faster as it grew. It was getting slower in ways that were hard to see because each individual piece of work was still getting done.
Rethinking What Ownership Meant
That was the point where I started thinking differently about ownership. Not as a rigid assignment, this designer works on this product, but as something more specific: this designer has enough context to make good decisions about this problem without starting from zero every time.
We started creating stronger pairings between designers and PMs and giving designers more consistent ownership of particular domains. It was not rigid. Designers still moved when the problem genuinely required it. But there was a home base. A set of problems they understood deeply. Stakeholders they knew how to read. Technology they had spent time with. Patterns they had seen before and could recognise when they reappeared.
And that changed the conversations.
The designer did not have to ask the same five orienting questions every time. The PM did not have to explain the entire history of the product every time. And I did not have to sit in the middle of every decision, providing the connective tissue between people who did not yet have enough shared context to work without me.
That last part was probably the biggest shift.
The Thing Proximity Was Doing
When a team is small, proximity can do a lot of the work that structure eventually has to do. Everyone knows what is happening because everyone is close to everything. Information moves through the team because the team is small enough that it moves naturally, through conversation, through physical presence, through the informal updates that happen when you are all working in the same small space on the same small set of problems.
As the team grows, that changes. You cannot stay close to everything. The information that used to travel naturally now needs channels. The decisions that used to get made quickly in a two-person conversation now involve people who do not have the same starting context.
The structure we were building was not really about controlling who worked on what. It was about creating enough context and ownership that people could make good decisions without everything coming back to the centre. Without me, or the PM, or whoever held the most history having to be present every time a decision needed to be made.
A conversation I had with two design leaders about scaling design teams made this clearer for me. The question they raised, what changes when a design leader can no longer be the person representing design in every room, is exactly the question I had been navigating without quite naming it. The answer, I think, is that you have to build a team where enough people have enough context to represent design well in the rooms you cannot be in.
The thing that made us fast at three people was not going to make us fast at ten. And figuring out when to change how your team works, before the old way has stopped working entirely, is probably one of the less visible parts of scaling a startup design team.
You do not always notice the problem until you are already inside it.