Smooth Operations

Wednesday, 17 June 2020

#design
#designops
#operations
#organizations
#teamwork

How many connections are there in a team of two? One, of course. In a team of three? Three, of course. A team of four? Six. A team of five? Ten, already. What about a team of ten people? A team of ten has 66 connections. Yes, sixty-six.

This basic concept of network theory – that the number of connections between nodes in a network increases exponentially – is the basis for Metcalfe’s Law, which states that the impact and usefulness of a network increase significantly the more users it has. Metcalfe’s Law is often illustrated with the example of a fax machine: One single fax machine in itself is useless, but as soon as other people also own fax machines, the value of each machine increases.

Metcalfe’s Law is a blessing when you look at it from the perspective of networks like Twitter or the internet at large. The more users the more useful the network becomes. But in the example above, when we’re looking at a high number of team members, Metcalfe’s Law can actually lead to the opposite. When a team grows, more communication is necessary. In a team of three, it is no problem when everyone is constantly exchanging information with all the other team members. In a team of ten, this becomes basically impossible.

This perfectly illustrates why you can’t simply throw more people at a problem to solve it faster. And there is another challenge: People are not machines. By increasing the team size, you also amplify a complex web of human relations, different personality types, varying goals, experience levels, and skillsets. Managing teams is a challenge and the bigger the team gets, the more difficult this becomes. On top of that, when people have to spend ever more time with being part-time project managers, leaders, communicators, and coordinators, it reduces the time they can devote to products and users. Often, the result is a decline in quality and craftsmanship.

Over the last few years, the role of design within businesses has shifted. Many organizations have come to understand that design has business value and that design maturity is a competitive advantage. As a consequence, they have grown their design teams or started building up an in-house design team in the first place. With their teams evolving, for many organizations questions of how to best organize design teams arise. As a consequence, the practice of Design Operations, or DesignOps, has received more and more attention.

Other than DevOps, which focuses more on the tooling and processes that facilitate great developer experience, DesignOps has a much broader scope: It is now often defined as everything about design work that isn’t designing per se. So it is not only workflows and software, but all the work that you have to do around design to be able to scale design teams while staying effective and maintaining quality.

As Kevin M. Hoffmann points out in his An Event Apart talk on the topic, there is no one right way to do DesignOps. What you have to do to improve the workflows, processes, collaboration, and team culture highly depends on your company, products, and ultimately your team. He suggests that before you define any measures, you should first focus on the values of your company or team. What is it that you can agree on and that defines how you work and what you believe in? Only then, you can go on and ask more operational questions like:

How do we want to work together?
How do we know what our design team is working on?
Does the team work well with other colleagues from development or marketing?
Does the team have clear goals?
Are there regular feedback sessions – and how many do we really need?
Is the team producing work of high quality that meets your standards and is in line with your values?
How do you find and hire new talent?
How do you make sure they thrive in your organization?

If you want to learn more about DesignOps, Kevin M. Hoffmann’s talk is a great starting point. What I really like about it is that he focuses not so much on efficiency, which is the darling of many managers and also the main focus of methodologies like agile (“velocity!”), but instead on what should be at the heart of good design and thus DesignOps: People producing outstanding work together. So instead of increasing the speed in which your design teams work, for example, he encourages us to actually give people more time because they will do better work then.

In their effort to improve the operations of their design teams, many organizations put a lot of weight on workflows, tools, and defining processes. Of course, having a clear structure in your team can be of advantage and well-defined workflows can increase productivity, especially when it comes to repetitive tasks. But design work also has a “liberal arts” component to it. To come to innovative solutions, teams need to have a safe space to explore different paths, to think outside the box, to challenge assumptions, and to continuously improve the details of their work. Many of those aspects often go unnoticed if the person in charge of defining workflows focuses too much on efficiency and operations alone.

Finally, to build a strong design team we also need to establish a strong team culture. As Daniel Coyle writes in The Culture Code: The Secrets of Highly Successful Groups, this is best done by building a place where people feel safe and be vulnerable together to establish trust, and by providing a sense of purpose. Only then are teams able to reach their full potential. We should keep that in mind when we continue to think about how we can shape the future of our design teams together.