When I joined Miro in 2022, the company was coming out of a period of extraordinary growth. The pandemic had accelerated adoption dramatically. What had started as a collaboration product used by individual teams was increasingly being deployed across large enterprises. That shift changed the nature of the problems we needed to solve.
Enterprise customers needed administration, permissions, security, compliance, governance, analytics, and increasingly sophisticated controls. The product had to evolve, but so did the design organization behind it. My job was therefore not simply to hire more designers. I needed to build the team that could build enterprise Miro.
I Started With the Product, Not the Org Chart
Before deciding who to hire, I worked with my product counterpart to define where the enterprise offering needed to go. We were looking several years ahead across administration, enterprise adoption, security, and compliance.
That gave me a much more useful organizational question than "who should we hire":
What capabilities do we need in the design organization to deliver this?
I created a skills matrix that mapped the strengths of the existing team across craft and behavioral capabilities, then compared it against the needs of the future portfolio. The gaps became our hiring strategy.
We needed richer dashboards and complex administrative experiences but lacked strength in interaction design — so I hired interaction designers. Many of the enterprise problems crossed permissions, administration, security, and governance, and those problems couldn't be solved at the screen level — so I looked for strong systems thinkers.
The goal was never twenty identical product designers. It was complementary strengths. Within four months, I grew the organization from zero to approximately twenty designers. But the number mattered less than the composition. The product architecture was determining the team architecture.
Twenty Designers Still Need to Behave Like One Team
Scaling quickly creates a different problem: you can hire excellent people and still end up with a fragmented organization. That risk was high for us because the product itself was highly interconnected — a decision in permissions could affect administration; a security experience might depend on concepts used elsewhere in the product.
So I set a clear expectation: you may own an area, but you are building one system.
We created design principles together, and one mattered more than the rest: cohesion over consistency. We were modernizing a legacy product — some old and new experiences would need to coexist. Instead, we asked two questions repeatedly:
Does it behave like Miro? Is the mental model aligned?
Visual inconsistency could sometimes be tolerated during the transition. Contradictory behavior or concepts could not.
Design Reviews Were About Shared Context, Not Approval
I wanted designers to know what the rest of the team was building. If someone worked on administration, they still needed enough context on security to see where their decisions might create inconsistencies.
Reviews maintained quality, but they also created redundancy — a healthy organization shouldn't have a critical product area only one person understands. That led to another mechanism: the buddy system.
Borrowing the Buddy Model From Engineering
Each designer had a clear area of ownership, but was paired with a designer from another team who reviewed the work, understood the context, and acted as a second pair of eyes. Deep ownership without isolated ownership.
This spread capability organically. If one designer became especially strong in prototyping or a systems problem, that knowledge didn't stay trapped on one team — it moved from person to person.
Collaboration Also Had to Build Relationships
The team was fully remote, and many people joined within a short window. I wasn't only building an operating model — I was building a social system. We used jam sessions to bring the team together around one problem, partly because complex enterprise problems benefit from multiple perspectives, and partly because new teams need to build trust.
We added lighter rituals too — a series called Bring Your Hobby to Work, and in-person hackathons. In a distributed team, they weren't secondary. You can't ask people to challenge each other's work or share ownership without a relationship underneath the process.
Designers Accountable for What Shipped
I didn't want designers to think their work was finished when the Figma file was handed to engineering. We introduced bug-bash days where the team reviewed the shipped experience and hunted for quality issues — shifting the definition of design responsibility from the artifact to the customer experience.
I reinforced that through goal setting, moving from output-driven to impact-driven goals. Not "ship the permissions redesign," but "improve the experience of configuring permissions." One measures delivery. The other measures whether anything actually changed.
Then AI Changed the Organization Again
AI wasn't another isolated feature area — it touched permissions, administration, security, compliance, data, and the end-user experience all at once. So the organization changed. We moved from domain-based ownership toward end-to-end journeys — particularly AI Adoption and AI Security.
When the architecture of the product changes, the architecture of the organization should be willing to change with it.
The Organization Became a Reflection of the Product
Looking back, the most interesting part was how closely the organization evolved with the enterprise product itself. I wanted the design organization to work the same way the product needed to: clear ownership without silos, coherent across surfaces, able to evolve as new technology changed the system.
That was the real work behind growing from zero to twenty designers. I wasn't scaling headcount. I was building the design capability Miro's next chapter needed.