When I started my career in technology I thought the best thing ever was the ability to make things work, so I started learning multiple programming language and building things. I then realized people using my software were having problems, so my next guess was to learn graphic design. Better, but something was still off: even if it looked good and the features were there, users were still having problems. I then switched again, moving to user experience, service design and information architecture. This combination worked well, but the ability to build useful services was still limited by one thing: me. I couldn’t do everything, so I started learning business, management, and organization design. There I realized that great products don’t just come from great technology and great design, but how the people that work on it communicate and interact together as one. Great products are shaped by the organization structure first.
Among many rules of thumb that I find useful to structure teams and organizations, two keep coming back as foundational pieces for many other different models. They keep coming back because they seem counter-intuitive in one way or another.
The first is Conway’s Law:
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations
Mel Conway
The second is Dunbar’s Number:
Humans can comfortably maintain only 150 stable relationships
Robin Dunbar
While both have nuances in their interpretation and shouldn’t be applied to the letter — for example Dunbar didn’t refer to just professional relationships, and the ways systems “copy” the communication structure can vary — they still provide a good general guidance.
The consequence of these two laws combining is that no matter what, at some point a company that grows will encounter communication issues, and will require to be divided in different units. I experienced this myself directly: up about 150-200 people I was able to have a general pulse of Automattic as a whole, beyond that it became impossible to form an even general idea, and even less to know everyone in the company.
A way to offset this limitation, that will lead to the common problem of silos, is to keep the company structure fluid, not just in terms of processes, but also changing the teams and moving people around more than normal. In a way, it means working with dynamic silos: providing stability for a certain amount of time and then, when work wraps up, shuffle things.
Another way to achieve this level of fluidity is the teams should also be allowed to experiment freely. The idea is that any experiment, even if it’s a variation from a shared norm, is meant to improve things, and as such even if not successful it would provide a good learning experience on how the current process work.
While I was leading Hyperion we ran a good number of experiments within our team – about three every year – and the most successful ones spread to the entire company over time.
Success at an organizational level requires involving the whole organization.
We experimented by changing the way we summarized weekly updates. We used to have two check-ins every week: one where everyone logged the most important activities they did, one where we discussed the progress so far. We decided to try for a month to fold both of them into one: in the middle of the week we reported the activities done before the chat. It was very effective, as it avoided to interrupt the work twice every week – which felt like a chore – and provided a moment to pause right before our chat. This in hindsight seem one of the things that are “obvious”, yet at the time we just borrowed practices from our previous teams so we had the split. During the experiment we also baptized the check-in and call as “Teachat” as we discovered that everyone on the team prepared tea right before the video call.
This experiment, even if successful, wasn’t picked up by many other teams. It felt just a minor optimization to them, even if for us it removed a frustration point.
We experimented by trying every day to do what we called text standup. For a month the moment each one of us arrived online posted a brief summary of what they did the day before, and what they were planning to do today. Takes just a minute. Simple right? So simple it almost seem irrelevant. Yet, this simple created a lot of benefits: we were aware when people came online, regardless of timezones. We knew what they did, and we were able to ask questions, advice or ask if they needed help. Was also good as a self reflection to see how the day before plan was different from the outcome. This approach was so successful that in just a few months spread to the whole company.
We experimented with OKRs – Objectives and Key Results, a framework to define and track objectives. We did a deep dive in the theory and practice of them, how to set them, how to keep us accountable, and we started experimenting. Initially it seemed very beneficial, as allowed to have clearer goal and explicit metric that other teams could see too. However, after a couple of iterations, they felt not very useful – for a a mix of reasons – and we dropped them as routine after writing a public retrospective on what worked well and what didn’t. Surprisingly, a few months later, other teams in Automattic picked OKRs up again, and they became widespread: even when not applied to the letter, they were still used as a way to frame projects.
We experimented with an idea kicked off by a colleague, Sara Rosso, and we tried to give to it some structure: project threads (previously master threads). Every time we started a new milestone in our roadmap, we posted on our team P2 (a specialized blog for collaboration) the outline of the milestone: what’s the goal, what are the metrics, links to all the design iterations, developer resources and tests. It took a while for us to find a formula that worked, but once we mastered it it became invaluable: if you wanted to know the status of our team, you could have just looked at which of our project threads were active, and what was the latest update there. No more scavenging for information. As project threads were a bit more structured, it took a while for them to spread to Automattic as a whole, and we also built some extra plugins to leverage them: now we have a dashboard aggregating them, a special styling and special tag, to differentiate them and make them clearer.
One of the great things of how Automattic is organized is how much attention we place in refining our processes — bottom up — in ways that don’t just improve our work, but also reduce the feeling of bureaucracy that often happens with companies growing.
It’s easy to underestimate the effect of these small changes, but if you imagine every team in the company to do even just one or two experiments every year, if you multiply by the number of teams, it then adds up to a much larger company transformation in just a couple of years.
Automattic Design 