Dear (none)Designer,

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

Addressing the topic of high-performance teams, we have received a shocking number of requests to go into the details of how these teams are set up and what specific techniques they use. Our main platform, Design at Scale™ – Academy, holds all the answers in detail. We help individuals like yourself to frame and act on the challenges of your own team.

There is no one-size-fits-all method. As this may vary from case to case and from team to team, especially across different industries, there are some common patterns that we can explore to give you an idea of how high-performing teams can operate at scale.

Welcome to the power of one.

A very simple framework of four pillars that allows all parties to stay in the know. Mobilyse and support each other to make an informed decision in that specific role without impacting anyone else's time.

The power of one has a simple premise:
– one language
– one location
– one team
– one product

As previously highlighted, communication is a key to all successes, and yet, according to the latest research in the 21st-century era of AI, we are still wasting 82% of our time finding the relevant information to make informed decisions. I know the number is staggering and somehow unbelievable — just for the moment, pause, ask yourself where your latest document is, how many times you have to ask your colleagues to find out what the latest decision is. How many times do we have to go through the teams, Slack or another communication medium to find out whether the meeting is external or internal and where we have formally agreed that we are building or who is going to give us a sign-off, so that we can move forward.

One language stands for the state where all parties agree on what and how the team will communicate in order to increase efficiency. How might we organise and name components, layers, files, documents and also how we extend this communication to an email, SOW, contract, or PiD – Project Identification Documents. To some, this is utopia; to others, this is reality. The difference is in detail, the organised team tend to outperform their counterparts by 30% – that is one and a half days in a week.     

Inevitably, this reflects on how we write our user stories and how we address business, consumer, and technology. Last but not least, on how we communicate the output that drives the positive outcomes for the business.

As the majority of these "names" are defined by the different departments, every single one of them might have an opinion on how to drive them and how they need to be organised; however, they are seldom shared and acknowledged by the broader team. Therefore, rarely do these ambition gets adopted across departments or functions. Occasionally, companies see the benefit in hiring professionals to optimise their internal workflows. It is often seen as a weakness rather than an advantage of the team. I have an opportunity to coach over 50 teams in the UK's largest financial organisation and align their naming convention into a single strategic language that allows all parties to communicate effectively. Defining shortcuts, abbreviations, and industry-specific nomenclature that reflects the functionality of the product or service that's being designed a nd built by the assigned Design team.

On average, we have saved 20% of the time on finding a specific document and making an informed decision in one team.

Now you might ask: "That's great, our files are in SharePoint, Teams, OneDrive, Monday.com, Slack and many other different locations". Unfortunately, some of the businesses are forced to have multiple tools, as one team works with one tool, another team works with another, because they are used to it. This translation, from the environment to an environment, is extremely costly. We have therefore run an experiment with one more dependent and more technically advanced team and moved everything into one location. No Drive, No SharePoint, No Slack, No MS Teams – radical right!

By moving all in one location – Atlassian, we have our tasks and coms in Jira, documentation and agreements in Confluence and code in BitBucket, all talking to each other. Simple adjustment of business, design and development space collecting PiD, HLRs, UAC, FR and NFR all respecting the above-mentioned naming convention. After 2-3 weeks of explanation and coaching/the adjustment team was set out to deliver the feature. Surprisingly, after concluding a survey, no one missed Teams, no one needs more clarity, and no one has asked for additional info. Why? Because it has all been documented as we deliver the proposition.

This brings us to the one place, and you guess rightly, yes, it was Atlassian. The place where everything is connected together under the umbrella of "knowledgebase" that is necessary for operating the delivery. A significant advantage allowed the team to concentrate more on design than on texting and fuffing. It reduced the time for the response, waiting and wanting for someone to come back to your query without context. Everybody asks their question in an appropriate location, business, design, in design – you get the sense.

Knowing where the documents are, most of the time, teams actually enable teams to work closely together. Slowly shutting down external locations and throwing the documents together empowered the team to spend more time together. It also feels like they are building, describing, and maintaining the same thing instead of their own little local storage. Even for the members who were across the world, they were all collaborating in a single space. Reduced revisions allowed us to reach the agreement 60% faster. The understanding was shared and recorded. Distribution of the knowledge went down to zero as the engagement with the space was constant. This allowed us to incredibly increase the velocity and deliver the product three times faster without actually changing a single point (sizing of the complexity) on the feature.  

One product was not a dream; it became a reality. The reality of a team that focuses on a single product. No site conversation about different features or functionalities. Every decision is well documented and optimised, but one team is building one product.

In week five and some extra training, we have reached the velocity that one single team of nine people has been delivering 21 story-point features without any tension, dependency or delay. It has even doubled in six months, and we have reached and delivered the product that has been launched in 48 countries around the world. That, however, is a different story.

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.