Welcome back to our Design at Scale – Academy series, focusing on the design practice in a team of ten. The previous article describes the series basics, and today, we’ll look at your initial step in the team of ten (essentially your product team).
We describe the team of ten as a minor product team of ten members, most likely – a product owner, scrum master, solution architect, UX designer, UI designer, front and developer, backend developer, QA engineer and researcher; this setup could variety to the team to team, but in general, all of these functions are included in a team of ten whether they are stable(ongoing) or just fluctuate (borrowed) for the specific part of the release.

Your Impact

Let's say you got lucky and got a job in the team. There are new members, a new team, and a new place, let alone potentially even a new location if you work remotely. Before you start analysing others, you must understand why you are there and picked up this particular role. 

Why are you in the team, and what impact can you make? 

Whether the team delivered the service function or the product, you must understand your role. Several aspects will judge you and, more importantly, evaluate your success. There are several books and academic studies that you’ll come across. Our approach is based on over two decades of research combining HBR, MIT, Stanford, and UAL methods (all included in the course below) relevant to this scenario. We have distilled the work of these authors that are relevant to the design and the scale; that is why our evaluation is not 300+ pages but a simple 30-question table that helps you decide where you are. Without a genuine understanding of why you are there and what your function is, you’ll most likely (in 72% of cases) misinterpret your role and direction, and the impact of your actions might come across as erratic or dysfunctional. My suggestion would be the following: 

• Why am I here?
• What do I offer to this team?
• Why does my expertise matter?
• Who will benefit the most from my knowledge or the action?
• Am I here to advise, analyse, make, deliver or integrate?
• Last but not least, who am I delivering to?

Let's carefully look at the above questions and paint the scenario you might be dealing with while answering them. As in any work, details matter. I would not place any assumptions about where you might be and what you might do. Our reflection of the following lines lies in the 20 years of experience and over 5,000 plus interviews of people who have joined the different teams and faced these challenges, and here's my thanks to them for sharing their parts and growth through the Design at Scale™.

Why am I here?

Well, it's pretty obvious you've got the job! Well done if you are in an existing function and have just been promoted to a different team; well done, you, too! Now, I want you to step back, find the quiet corner, draw a tiny diagram, put yourself in a centre, and draw the 5-10-15 points where each of them will represent one of your colleagues.

What do you just see in front of you? 

It's a diagram of the functional integration we will explore later; don't worry. Around every person, please draw another circle where you can go and identify their strength, weaknesses and opportunities. The way they communicate and how you're going to communicate to them.

In order to find out why you are here, why not grab your colleague and ask them why am I here? What is so special about me? Most of the time, the genuine answer is the most from all these answers, concluding, and if you can remember them or make a note out of them, make them count. 

What do I offer to this team?

As this may sound quite obvious, designers are often higher not because they are creative but because they can deliver particular outputs that can be further integrated with the rest of the team. Creating a so-called value proposition for the business or the function in an industry that you play a vital role in. It is, therefore, inevitable for you to understand what you offer to this team and on what basis. That's why one of the questions you will ask your colleague could be what role I play in this team. Don't worry; every great player in American football or the British Premier League will ask the same question. It's a team game; in the book “It Takes What It Takes”, Trevor Moawad – describes what neutral thinking does to the season and the team's success. Translate into the design world; you have just one release to show how good a designer you are and, therefore, what you are offering to this team is vital to your success.

Why does my expertise matter?

You may pass some interview questions or growth within the existing team. Your experience inevitably has an impact on what you do. Your expertise is not only in delivering but also in advising and communicating. Sense, response, and power of one will give you the pivotal point of your career. At this point, you have to understand your expertise, whether it's advising, navigating, articulating, showing, division, adjusting, innovating, making or delivering. 

Most designers need to understand their expertise and emphasise navigating and articulating where the main expectation is on delivery. Once you identify your expertise, you gain 50% of the time to not always focus on something that you cannot influence; more importantly, if you want to get better at it, you have 50% of the time to get better at something that no one ever asks you to do.

Who will benefit the most from my knowledge or the action?

That brings us to another point: who will benefit most from your understanding? Product teams are mainly organised, so the design is merely a supporting function. Do not worry. This is not a bad thing; most importantly, it gives you the time to fully understand the complexity of the proposition and prepare yourself for the inevitable changes that only you can make. Your knowledge is here to be translated into something that is far more tangible, whether this will be the set of screens, the design system, or the documentation. Make sure that everybody who works with you benefits from whatever you create. If you are a system designer and you are creating the design systems, work closely with the engineers so that whatever you create as atom elements or components can easily translate into the code that can be implemented in existing or future prepositions. 

That's it. There is a small caveat: Over the last 20 years, the extensive line of designers have succeeded not because they create a beautiful proposition piece of UI great design system architecture but because they document their success in a way that the business operation engineering and integration can understand that and translate it into a value proposition for the business. In other words, it's not about how beautiful your wireframes are, but it's about the value they create for the engineering team to understand what needs to be built.

Who am I delivering to?

That leads us to the last point: who are you offering to? Many designers wrongly assume they provide their service to the function or business, to the unit, or to another design or engineering team in a different building. In 9 out of 10 cases, you deliver the colleague right next to you. Most importantly, you provide within the team that is, for a particular time, your family. Only the one that will evaluate your commitment. That's why it's vital for you right in the beginning to understand who you are delivering to.  I have often discussed with the design director or, in later stages, with a product owner that every day at 5 o'clock, I provide a so-called increment of my work. Hence, there is a clear understanding of the progress. Still, most notably, the proposition will evolve over a particular piece of delivery that impacts the overall team velocity and creates business value.

Come and join me in this series to become a better designer on a team. We offer the three-hour courses in Design at Scale™ – Academy, where you can get tailored answers to your own team—followed by the support community that addresses the very challenges of the scale ––> Register.