Flat out change: balancing structure with culture

Building an engineering organization is hard.

In an ideal world, we build teams that respond quickly to customers and markets. But organizational change creates friction. People need to learn to work together through what’s called the forming, storming, and norming phases.

At Typeform, we started out with a completely flat company structure. Teams didn’t exist yet, and our codebase was shared across the company.

But as we grew, we realized that our utopian (and totally flat) organization just wasn’t sustainable. Communication was strained, work needed coordinating, and our codebase began to grow.

It was time to add some bumps to our flat org. But how do you add structure without harming the collaborative culture you’ve worked so hard to create?

The Spotify experiment

Over the last 20 years, the software industry has tried all kinds of ways to build organizations. In the beginning, teams were grouped by function—mobile engineers in one team, back-end engineers in another, and so on. Makes sense, right?

Well, maybe for smaller companies. But as we found out, things get more complicated as companies scale.

It was time to try cross-functional teams. Our rationale? Agile software development requires agile organization. Spotify is a thought leader in this space, openly documenting and discussing their experiments. And they’ve done pretty well for themselves.

So here at Typeform, we tried to implement what is now known as “The Spotify Model.” Who could blame us for wanting a slice of that Spoti-pie?

But after a couple of months, we realized that something just didn’t feel right. Walking through the office, you could overhear people trying to make sense of the details behind Spotify’s system.

We spent weeks debating the finer points of “What’s a chapter?” and “How exactly do tribes work?” And we were soon forced to admit that we spent more time thinking about Spotify and their terminology, than building a structure that worked for Typeform.

So, we decided to come up with our own model and new terminology that brought a little “buzz” to the office.

Learning from bees

Where do you even start when rebuilding teams? First, define goals. Ours were to:

• Build an engineering organization around cross-functional teams.

• Split teams along the major parts of the user experience: allow developers to build a strong relationship with their part of the product, and better understanding their users.

• Create a model that would scale as we grow.

Then we laid the foundation for cross-functional teams. We call them “swarms.” These autonomous teams have their own set of business metrics and skillsets. Members include front- and back-end developers, UX/UI designers, and quality assurance staff.

But this brought up another question: how do we organize swarms in a way that keeps people focused and gives them ownership over their work?

We took our cues from Conway’s law: product architecture often reflects the structure of the teams that designed it. So we decided to cluster our swarms into “colonies” centered on a distinct stage of the Typeform user experience.

Here’s how it works.

Every Typeform user goes through a similar journey. They create a typeform, they collect results from end users, they connect typeforms to their favorite tools, and then they draw conclusions from the data.

So we initially formed our colonies around these four steps: Create, Collect, Connect, and Conclude.

Now the tricky part.

Each colony is made up of one or more swarms. For example, the Create colony is comprised of a single swarm. They work on the builder, which is what people use to create a typeform.

But the Conclude colony has two swarms: one for managing the database and results panel, and another for integrating with third parties to run data from Typeform into a range of apps.

Okay, so how does people management fit into all this?

Invest in people, invest in product

Typeform builds two things: a great product and a great place to work.

So we needed a special structure to work on things like career planning, goal setting, and personal development. And that’s what we call a “hive.”

The hive sits on top of swarms and colonies, and are mostly organized by functional skill. So back-end developers belong to one hive, QAs to another, and so on.

This decoupling of hives, colonies, and swarms keeps things flexible and scalable, allowing teams to expand and contract as needed. Swarms may get shuffled around, but hives remain untouched.

Introducing change

Ever walk into an office and someone tells you that your desk has moved somewhere else? Feels nice doesn’t it. We knew that even the smallest  changes can cause stress, internal friction, and a dose of skepticism.

So we wanted to make sure that we introduced these changes as smoothly and transparently as possible.

Instead of getting everybody into a big meeting room and dropping the new organizational bomb, we introduced the concept through a series of smaller meetings. This helped people understand the benefits of these changes. More importantly, it gave people a chance to give us valuable feedback.

We listened to what people had to say, and even made some changes based on their suggestions. This made everyone feel included in the process, making the transition to hives, colonies, and swarms as smooth as honey.

What have we learned?

It’s been almost two years since we moved to this new structure. The overall concept has held, but we’ve made some adjustments along the way.

For one, we realized there’s more to the user journey than what we thought. Our original four colonies—Create, Collect, Conclude, and Connect (the 4 C’s)—missed two crucial steps of the user journey.

People discover Typeform through our website, blog, and help center, all of which need developer resources. And once people know about Typeform, they sign up, change plans, and manage their accounts. So we’ve added two colonies—Discover and Subscribe—to take care of these user experiences.

We also learned that for managers to be effective, they can’t be completely removed from day-to-day operations. Duh.

When we started, managers worked with engineers across all teams. But they ended up too far apart from the teams and their work, which made it hard for our managers to, well, manage.

Solution? Move managers closer to colonies, which gives them more visibility and impact on the swarms.

We’ve also realized that structuring the colonies around discrete user experiences creates silos, making it hard for us to work on features that span different parts of the product. With Typeform growing, more and more projects cut across the product, which makes working in colonies a bit trickier. This is something we’re still trying to figure out.

What’s next?

We’ve made plenty of adjustments along the way, and surely more tweaks will be needed. But keeping teams small, modular, and agile lets us move with the times.

Because in the startup world, change is always just around the corner.

And speaking of change, have you heard about Typeform v2?