Dear (none)Designer,

Welcome back to the twenty-eighth Design at Scale™ Newsletter – focusing on innovation and how design drives change in a large organisation or an agency.

Building a high-performance team sounds like an incredible challenge when, in fact, it could be pretty easy to do in your business, your agency, or your organisation.

Before we start building the team, let's define what a high-performing team is and how we measure its impact on business, design and development. At first observation, let's make sure that what's high-performance for us is the same as the high-performance for the business.
High performance is often connected to the business, and therefore, to time, revenue, and operations. It is equally touching the topic of human resources and how we, as humans, perform within a very specific environment. Last but not least, it comes down to the profession, in our case, the design. What role does the design play within the organisation, and how well it is represented?

These three factors directly impact the perception of high performance while equally dictating how it is received and respected within the organisation.
The agencies are perceived as a high-paced business where all designers are constantly being moved from one project to another to maximise time and charge higher fees for the work delivered within a specific timeframe. What is the distribution of the time playing the role in the performance? The majority of these teams are performing their basic delivery instead of excelling at it. It is often due to constant adjustments that are necessary as the project's dynamics and objectives constantly change.

The majority of the designers in Europe are often part of the teams that are highly controlled by the project or programme managers. Therefore, the self-organising teams are a rare minority. Yes, we can see some exceptions, especially when the US business has some subdivisions in EMEA and APAC. On the other hand, our American colleagues have a firm belief in the flexibility of self-organising teams that require less reporting and therefore less adjustment, which impacts delivery. These teams often outperform their counterparts by 30-40%.

Let us assume you are in an agency with between 20 and 80 people. This way, you, as a designer, will eventually be exposed to at least two or three projects or one project with 2 to 5 different work streams, which we call medium complexity.

To increase the productivity of such a team, you would most certainly need to simplify the flow between idea and execution. To do so, you need to minimise the changes that impact your team. If you have more than 20 change requests in a week, you will most likely end up making changes instead of scaling your team's performance.

As simple as this sounds, it's not about the designer being unable to design more, but rather to understand where the change is coming from. What can be combined, minimised, prioritised, and, most importantly, automated within the timeframe allocated for execution? Once you gain control over all the tasks coming your way and have decided on their priorities— low, medium, or high —you will be able to adapt your approach between qualitative and quantitative delivery.

Product-driven delivery will enable you to create assets that can be multiplied and subsequently redistributed in various ways. Occasionally, qualitative delivery will be seen as impactful (which is mainly due to not understanding how things are done); on the other hand, quantitative delivery will always be seen as the most impactful one, especially for the team and the business.

It goes without saying that quality comes first, and designers pay a high price to have the time to reorganise, reform and refocus. The new distinction of tokens, modules, and layers in your files serves as a catalyst for others and brings a significant difference to all.
You will therefore create more schemas and models to navigate how you structure, communicate, and organise the delivery, which changes directly impact performance. When the time comes, you will be able to produce and overproduce outcomes for different audiences across multiple touchpoints.

Of course, everybody is searching for new plug-ins, new extensions, and new automations and probably for the possibility of reinventing themselves. In fact, nobody was creating the library for their own use. A knowledge base that allows you to outperform the best, as seen in businesses where people have thousands of plug-ins, but none of them have delivered the expected value. How to challenge it and change it?

That essentially involves three steps: mobilisation, operation, and acceleration.

To begin with, you need to consolidate all your assets into a single location. It's called gap analysis, and that way you'll understand what you're dealing with. Then you align your knowledge with your analysis. Your goal here is ruthless cutting and rewriting, which is essential to create a templatised version of your current design environment that will serve the maturity of the cases. It is better to have nine outstanding documents than 90 mediocre documents that do not serve the purpose of the delivery.

Your new foundation will enable you to stress-test it over several projects and deliverables. This new structure will eventually move into an operational stage. The period during which we focused purely on business impact. Your organisation will love it even more, as this part is designed to make the most of the money. Improving all your early assumptions and mistakes will result in the basic 9 nine pillars we'll debate and stress-test over the next +100 articles on GRID Managzine. Not because we need to make a point of impact, but because we have consulted with many teams that use it differently, and some might benefit from understanding how other teams deliver design decisions at scale.

Allowing us all to debate, challenge, redesign and improve these nine pillars. This way, you will create an incredibly strong foundation that serves across business, design and development to deliver quality products and services within a short period of time.

After about the 3 to 6 months you'll reach the stage then you can start scaling these documents are solid and offer you stability and consistency that you can already see across your entire landscape your colleagues already started using your name in conventional nomenclature and communicating in the same manner as you have set out this way you will enter the stage of scale which we call acceleration.

The structures and understanding are adopted and well received, which allows everybody to simply focus on the work and not have to search for documents, look at the teams, or find out what the latest message from the client is or what the latest decision on the local is that we have to apply across the breakpoint.

Well-organised teams are well-performing teams. It does not come from more plug-ins, more technology, or more predictive suggestions in GPT Chat. It mainly comes from the radical simplification of a fundamental agreement on what needs to be done and when.

For more information, please visit Designa at Scale™ – GRID Magazine, where you can find additional relevant articles that explore high-performing teams, self-organising teams of 001, teams of 010, and teams of 100 that deliver the value proposition within a product-led environment.