It feels like 2019 is the year many companies realised that without a great customer experience their product would struggle to compete. Recently we've seen traditional companies expand their design teams, as well as starts ups from small to hypergrowth. However, this is uncharted territory for many.
Jane is here to give you advice on how to set your teams up for success. Her experience covers companies of different sizes, both legacy and start up. She has set up or scaled four different design and research teams - at a city trading firm, at The Telegraph , at MOO and now at Babylon Health, where she has grown the team from 6 to over 70. She also acts as a consultant to smaller businesses. In this talk she will cover tried and tested strategies for setting your team up for success.
1 / 85 Use ← → to navigate
Auto-generated transcript - may contain errors.
Tap a timestamp to jump the video.
Hi, everyone. I'm Jane. You wouldn't believe the things I've seen. I've grown teams. So at GDS, I was a government digital service. I was at The Telegraph, the British newspaper, and I grew the team there that was one, which was me, to over forty.
Then I restructured and grew the team at MU, and now I'm at Babylon. So if you haven't heard of us, this is our mission. If you haven't heard of us, we are a health care start up, an artificial intelligence health care start up, and this is our mission, which is absolutely incredible.
So when I first went for my interview, this was emblazoned at the top of the stairs. I thought, God, I want this job. It's such an absolutely unbelievable mission. So we are with telemedicine, so you can see a doctor remotely. We are AI powered triage tools and predictive health modelling tools.
We have a chat bot. We also support and manage lots of chronic conditions. The first place we opened was in UK, and the second place we opened is in Rwanda to prove that this model would work in rich countries and poor countries. And it's a really fantastic place to work.
And this is what I've done. Basically, in the last well, since ten months, I have seen probably more portfolios and interviewed probably more people than anyone else in the UK right now, I'd say. We're scaling incredibly quickly. So the issues I think that we're having are quite similar to design teams of any size, but their issues are hitting us probably faster and bigger.
So what I'm going to do today is share some of the strategies that we're using to help mitigate these problems that we're having, and I really think they're going to be helpful, even if you have a team of one. Things I'm going to cover today is design maturity, what this means, what a team structure would be like, how to hire, how to codify your design practice, and then how to scale your culture.
Let me first start with design maturity. There's lots and lots of design maturity models, but I'm going to offer this very simple one. It's basically based on who makes the decisions and how. Level one, I call this coloring in, and this is usually a symptom of an organization that works in a very linear waterfall way.
So basically, you have the developer. The developers just maybe put a Jira ticket in for a button to the design team, and they're just coloring in with very little power. This actually was the position the team was in when I joined Babylon. They were at the end of this long chain of processes, and they were very, very restricted in what they could do and what they could impact.
Although the team was excellent, there was very little that they could actually do. And this is actually often the most difficult position to scale from. Then level two is when you have designers actually embedded in the team, and level three is when you have data and research.
You're actually making much more powerful decisions. And level four is the nirvana, is when you have design and research actually impacting strategy and having that seat at the table. When level one, you can often end up being this thing called a feature factory.
So, feature factory, you can recognize this by there's no objectives. So, another way to summarize this is projects, not products. This means that the work has absolutely no connection to the customer and business outcome. You don't know why you're doing this. The team is just working on stuff.
If you have no metrics, this is another sign of a feature factory. The teams don't measure their work, so they don't know if they've been effective. Or if measurements happen, it's done in isolation by product management, and then it's selectively shared. You have no idea what you've shipped has actually worked.
This leads to success for theatre. Success for theatre means that you're just kind of celebrating that you've shipped rather than actually what impact you've had. And also, this means that people get very hung up on velocity as a sort of metric to say that their work has been successful or not.
This means then that you don't acknowledge failure or learn from it. So features don't get removed. You just don't stop doing something when new information comes to light. So the teams plow on building this thing that nobody wants or needs, and it's incredibly demoralizing.
This also means that the team are really obsessing about prioritization. So product managers are doing lots of prioritization instead of actually trying to think about what the end outcome would be. This ends up with a team chasing lots and lots of upfront revenue.
This is a really problematic way to be in the team. How do you increase your design team's maturity? How do you get out of this feature factory or being at the end of this long process and doing the buttons off of Jira tickets?
It's about showing the impact of your work in the language that resonates with key people in your organisation, so those people become your advocates. Because you can't just force an organisation to change, The organisation has to want to change, and the way that you do that is by demonstrating the impact and the benefits of your design team.
I think it is important to realise that this is a journey, and you have to take it in stages. It is really difficult, as I said, to go from design as an order taker or being in this kind of feature factory to becoming strategic partners in one step.
So it's not really your choice as a design team if this happens or not. You have to continually prove the team's worth and widen your circle of influence. One of the ways that I did this at Babylon, we've just finished this. So at Babylon, there was like when we first started, as I said, we were a very small team.
We were doing Jira tickets. Then we were starting to get more power and influence. In this final stage, we were building lots and lots of products, and actually wasn't clear how some of these fitted together. It wasn't clear what problems the organization was having.
So I said, I can fix this, which was actually absolutely terrifying. I said to the CEO, Don't worry. I can fix this. I put up my hand, and he said, You've got four weeks. So we did this customer journey mapping exercise where we did lots of research.
We talked to customers, and we mapped out the experience of using the app end to end, and we discovered huge amounts of problems that the teams were unaware of. We also discovered that some teams were working on very similar things at the same time without being aware of it.
So this is this tool. I'll invite you back next year, and I'll talk about user journey mapping. This was the tool that we used to get the team to become strategic partners in the organisation. And now, everything that we do, we have to have this continuous user journey map.
We have to make sure that we understand what the impact on the customer is, rather than being engineering led. So the next thing I want to talk about is team structure. And one second. So what kind of different team structures can you have?
These are the four models that I've seen in organizations that are starting in scaling design, and I'm going to talk you through the pros and cons of each. The first one is an agency. Usually, this is when you have a business or a start up, They don't really have design capacity, so what they do is they outsource it to a third party.
Another one is a centralized team, which is almost like an internal agency where the team all sits together, and they have Jira tickets or something coming in, and they have to work on it together. Or the other option you have is the centralized partnership, which is designers there embedded in different squads, but they're controlled centrally, and you may have some kind of central management team.
Or you have designers which are fully embedded in the squad, and those squads are empowered, and they can decide what to work on themselves. So at Babylon, we jumped straight from centralized to embedded, which meant that we could scale really rapidly, but it caused huge amounts of problems, and more on this later.
So how did we fix some of these problems? Well, the way that you can have design working effectively in an embedded team is to have this notion of the triad, the three legged stool. So you have design, tech, and product as equal partners.
We have done something slightly different. We call this the Quad. We've added data and research to this group of people, which means that we make really informed decisions, and that we're able to test, measure, and learn continuously, and that we are able to make sure that we are building things that customers actually need.
So how does this work in practice? We have some principles about how we see the quad working. Each discipline is kind of like pool factors or force fields that attract certain types of work and responsibilities. And the idea is that responsibilities are aligned and agreed based on context, and that the people are playing the roles.
So as trust develops between the roles, you can be able to perhaps only have two people at a meeting instead of all four. And this means that we have trust, and it means we have consent, not consensus, so you can move much faster.
So, look at what we are responsible for. We have product. Product in this notion is about shaping the future of the product and setting up the product vision. I call this building the right thing. We also have design. And design is straddling both the strategy, which is building the right thing, and the execution, which is building the thing right.
Then we have technology. In this model, technology is about execution, and it's about building the right thing. And here we have research, and research spans two aspects. One is generative research, where we are looking to the future and trying to understand what we should build, and then summative research, where we try to understand what we have built, does it work, is it effective?
Together, they are going to build and own and run and iterate great products. So, how do we actually set up the teams in Babylon? So we have a design manager. So this was the first person I hired. And at this point, we didn't really have the infrastructure to support junior people.
So when I'm setting up a team, I always start with the most senior person below me. This means that when you hire these people, you need people who can deal with lots of ambiguity and run their bit of a team, sort of like the tribe or the squad, and then they can help you with recruiting with the business.
So the first person I hired was a design manager, and then they built out their team. Then the next person I hired was a research manager. We have this kind of matrix management, where the design manager and the quad tell the designers and researchers what to do.
But we have research managers who work across horizontally and ensure that we have really good quality, high impact research. And similarly, we have the design manager working across also to make sure that the design is executed to a very high standard, and then we just continue to grow this out into different squads.
So now I want to talk about hiring. Hiring is obviously if you want to scale. It's the most important thing you can do. But who do you hire, in what order, and how do you find them? The first thing to do is assess your existing team.
That's really tricky. The first thing to do is assess your existing team. At this point, I had developed career ladders, especially for Babylon, so I took that, and I overlaid it onto this tool, which is set up by a man called Jason Mesut.
These are all the different things, as you see, all the different skills and requirements that a designer needs at Babylon. And I sat down with each of the existing team members, and I got them to fill it in with me. That way I could see the shape of the team, both in terms of their craft and also any soft skills that might be missing.
So when I went to hire, I was able to understand how to fit people together. The other thing is I fixed the hiring process. So I had a recruitment partner, and I also made sure that I trained everybody that was hiring. So we had a very similar set of standards and processes, so I didn't have to be in every interview.
The other thing we started doing was actually defining the culture as well as the skills that were required. At this point, you have to trust your key hires to help define the culture with you. So this was really easy for us at Babylon, actually, because we had a defined set of behaviors that we could use to hire our guests.
So we have these pillars. This is our brand values. And for each one of these, we took it and transformed it into a behavior that we would like to see in the interview. So we have compassion, so we saw that was ethical and cared for others.
Inclusivity, it's working in a straightforward, collaborative manner. We had tenacity, which was being tenacious in the pursuit of delight to our users. We were looking for people who were always striving for excellence in everything that they would do. We had creativity. Obviously, was very important for a designer.
We want people who could regularly take these ideas and turn them into something incredibly special. Positivity. That's people with a very can do attitude and a positive viewpoint. And ownership. We also found people who took ownership and delivered against what was agreed. We're able to take this and turn it into a set of behavioral questions that we used in the interview.
And then I got huge amounts of portfolios submitted to me. So what should you look for in a portfolio? Well, obviously, you need craft skills. That's really obvious. But you need context. You need the context of the work. Was the team scaling? Was there not hitting budgets?
Was there a problem? What was the candidate actually responsible for? Because I know as designers, we often like to say we, and we talk about a team. But actually, in your portfolio, you need to make it very clear what you have done. We also want to see how people have got to the solution.
Perhaps you want to show us in your portfolio different routes, how the design evolved, via feedback and research. And we also like to see challenges and problems, so like what went wrong, how you fixed it, do you have a growth mindset? And ideally, we want to see what the business outcome was.
So the next step is interviews. So I hate design tasks. Yeah. Changed my mind. I absolutely hate design tasks. So why is this? Well, I don't know if anyone remembers the story quite recently that Hertz are suing Accenture. I don't know if anyone's heard of this.
So, basically, Accenture went into a pitch to Hertz to say we're going to rebuild your entire website, and they did this beautiful PowerPoint deck with beautiful images, and Hertz said, okay. We're going to hire you because of this. So they hired them, but, of course, you can't just take a PowerPoint deck and turn it into reality.
It ended up being an absolute nightmare of a project. I saw this discussion on Twitter, and I thought, this actually sums up why you can't have this, like, do a take home task and try and understand if someone is a great designer, because there is no context.
People don't understand what the business constraints are. They don't have to work as a team, so they just created this beautiful artifact which is almost meaningless. Possibly the only thing you can tell from it is how they might go about something or what their craft is like.
So this quote here talks very similarly about, of course, how it's made the wrong decision because they just looked at something very, very shiny. So what we try to do, instead of sending someone a take home test, we bring them in, and we do a portfolio review, and we do this behavioral interview, as I mentioned, with the pillars of Babylon.
And these are the kind of questions we ask. We ask them to present two case studies. I'll let you take a photograph of the issue if you like. This is our cheat sheet for hiring. Everybody in the team who does interviews is trained in this and trained to understand how to interrogate the answers further.
Then we have a score sheet to try and make the hiring as fair as possible. Again, I will circulate these slides. You can ask me on Twitter, but feel free to take a picture of this. On this, we have a tool called Lever, and it's often the case that tools change your behavior.
In Lever, you have to score whoever you're interviewing out of four. So I've made this, which is five. Basically, one is you don't want to hire that person at all. Two, not great. Three, okay, but we're really looking for somebody probably three point five and above.
And if somebody is scoring five, well, actually, they've come for the wrong job. And this way, we systematize the interview process, and we're able to put this score, and we all understand what the score refers to. So, in the interview, we ask people to do this.
It's called the STAR. This is my top tip to you for interviews. So, it's your situation, task, action, results. So, if you frame your interview answers via this, it's a really, really great tool to make sure that you're explaining yourself properly, and it's actually a really good tool for putting into making sure you're structuring your portfolio case studies as well.
So once we've hired someone, the next thing we have to do is onboarding. So when we onboard, we have a thirty, sixty, ninety day plan. We give people clear objectives. It's really important. We have a list of who they need to meet and why.
We have a whole research repository that we have to link to. We give them a big presentation on our history and other teams, and then we keep reviewing the process. So actually, what we are thinking about doing now, because Babylon has got so massive and so complex, is actually creating a two d academy, so when anyone starts, they go through this academy and just understand how everything fits together, sees real users, etcetera.
And I actually saw a quote from a chap who had just started at Google. He'd tweeted out on his second day that there's a his view was that there's a real risk that impostor syndrome is actually just very, very bad onboarding. And I thought, God, was interesting.
So this has made me really focus on making sure that we set the people up for success by having great onboarding. And the next thing we did was codify the practice so that people were able to be assessed in all of their one to ones and their performance reviews in a very standardized way.
So I created career ladders. The career ladders, I completely went over the top. I'm going to show you what I've done, but actually, it was probably too much detail. So I've run it through one round of performance reviews, and it probably was overkill.
So I'm going to dial it back, and then I'm going to publish it, and I'm going to open source it. So please, again, feel free to take photographs. So the first thing I did was define scope. And this was the scope of the impact that the person has.
For example, a junior would be looking at a small function level problem like, you know, add to basket, whereas a principal would be looking at something across the entire product. I also called out leadership skills. So leadership skills are junior. Basically, all you have to do is kind of question your requirements, make sure that you really understand the project, make sure that you have a human perspective.
But as a director level, you're going to be doing things like leading the conversations about the director of the product or the strategy, looking at team wide consensus, looking at getting people to adopt the direction, trying to make sure that you understand the whole organisational context, articulating a vision for the team.
So this way you can see what you need to do in order to progress to the next level. Then I actually started thinking about, well, craft is obviously important, but what are the other things that people need to do in order to be successful at work that we haven't really articulated?
I've created this sort of onion. And my experience, the further way that you move from craft into personal, the less that these skills are spoken about, the less training and focus they have, but they actually have a massive impact on your career progression, and actually your day to day happiness.
So, as I said, I've been researching an enormous amount in this area, as well as creating multiple career lodges over the years. So, in my latest version for Babylon, I've tried to codify these non craft skills to help people understand what's expected of them, to help them progress, to help them have better insight in their one to ones.
The other person that helped me was this wonderful man, Johnny Birch. He has a fantastic app called Progression App. Go and check it out. So, if you want to do your own career ladders, he has selected all the best of them, and he's put them on his site.
It was ProgressionApp. Fyi. Go and check it out. So I'm going to show you all of the different skills, and I'm going to call out a couple which I think are particularly interesting. So first, I'm going to start near the edge of the onion with process skills.
And again, please take a picture if you want. So these are the process skills. And as I said, at each level, I'm going to pull out one or two things which I think is probably the most interesting. First, I'd like to talk about business context, because as designers, this is something that we often don't discuss.
I think the ability to understand business context is really this trait of a senior designer. For example, do you know how your organisation makes money? Do you know how much money it makes? If it's a start up, where does the investment come from, and how much runway do you have before it runs out?
What are the KPIs? How does your work count towards this? If it's government, how are policies affecting you? When I was a junior designer, this was kind of my view of the world. I don't get it. Fails one, collect underpants. Fails two, fails three, profit.
Oh, I get it. No, you don't fat ass. So, when I was first started as a designer, I had no idea, so I basically I would do my work, blah blah blah blah blah, and then somehow profit would happen, and I just didn't see the connection between any of these.
In fact, to caution retailers, if you're going to go to a start up and you get stock options, make sure you really understand what phase two is. Again, do you know how your work impacts your business? Do you know how to improve the product in a way that helps generate more revenue, or ROI, or how to minimize costs?
Do you know how much it would cost to build a feature, and what impact it would have? I've seen designers really fight for things to be perfect and say things like, The business doesn't get it. Actually, that's not true. Designer has to understand the business context, and you have to understand the impact of what you're doing, because not everything is equal.
So, not everything has to be perfect. So, you need to understand what you need to fight for and what you can let go. And that leads me to my next point, key process is agile delivery. So, this can have a massive effect on your career as a designer, being able to operate effectively in an agile environment.
So, there are structures and processes that you, as a design team, can put in place, although they're relatively subtle, they can create a cultural shift which moves design from being reactive to the needs of product and tech, and just building a list of features like the feature factor I mentioned, to actually starting to proactively read the conversation.
So what I've seen here is building on dev rituals and collaborative grooming so that devs understand the flow, the context, the big picture. Perhaps ideally, even get the devs to come and see research. Have whole team kickoffs that design can help facilitate. So design there starts to become and steer the conversation.
Have research, as I said, as a team sport. So, at the very least, make sure everyone in the team knows what you're building, why you're building it, what problem you're solving, who your users are, what outcome you would expect. Understanding effort versus value, as I mentioned, business context.
Do you know how much effort you ought to put into a particular feature? And then finally, breaking work into shippable influence, and then measuring the impact. The next thing I would like to talk about is people skills. Again, you can take a picture.
So, people skills, the one I'd like to really focus on is feedback. So, a senior designer, they can present a piece of work to the stakeholders in terms of here is the problem and here is the solution. I've often seen more junior designers doing a real estate tour, so that's the difference.
The other problem with feedback is that Edinburgh, so obviously Harry Potter is at the front of my mind, and I was thinking about designers. It's kind of like you put a bit of soul into your work, so it's like a designer's horcrux, you know, when the Harry Potter thing, where you put a bit of yourself into the spell.
It's exactly like that when you're a designer. You've got this beautiful work, people criticize it, and it really hurts. It feels like a personal attack. As you mature as a designer, starting to be able to take on feedback and give very clear feedback is a massive skill, and one that is not really taught.
The other thing that is not really taught is radical candour, about being able to tell people honestly what they are doing wrong, to tell people how to improve. As Brits, we are not very good at giving this kind of real honest opinions, and that's something that you would need to help your designers develop.
Which leads me to personal skills, the center of the onion. Working on these skills won't just get you promoted. I think they'll make you a better colleague. They'll help you deal with stress and ambiguity. And I might be claiming too much here, but I think working on these are going to make you better at your job and probably happier and more fulfilled because you are able to connect with people in a much better way.
Let me look at some detailed ones here. One of the key ones I find is the growth mindset. I know this is a bit of a buzzword. It means basically that you are self aware and that you learn from your mistakes. This is invaluable in growing in your career.
The other one is bias to action. Really, if you are not going to get something shipped, it probably doesn't matter. You can spend all this time doing decks, going off, and doing these beautiful upfront designs, nothing ever comes off. You need to make sure that everything you do results in some kind of impact.
So the next thing I'd like to talk about to set your team up for success is talent reviews and succession planning. Often organizations don't do anything like this. So we've been doing I'm sorry, this is such a hideous diagram, I've taken it from an HR site.
This way you can map, it's called the nine box talent grid, and you map people against skills versus potential. The other thing I've seen, and it's actually quite dangerous, I've seen organizations band people into top, middle, and bottom performers and then put a quota on it.
This is a really, really bad situation. It's actually what Facebook does. They have to have, say, twenty percent of people put into the bottom category, so the low performing category, even if they are not. This means that often managers are looking for excuses to put people into this category.
There have been some really interesting articles written about the pernicious effect of this on the culture of Facebook. It means people are scared to disagree, they're scared to challenge, they jump on high profile things that maybe don't have enough impact, and you can see how this perhaps can connect to the problems that Facebook is having.
So, although this grid is useful, and it doesn't have an issue of quotas, it does have one issue, which is this kind of perception, this bias around what leadership might mean. So that's something that you really need to work on, and try and understand what the culture in your organization is.
What does leadership mean in your organization? And then the next thing I wanted to talk about is tooling. So, right now, we have a centralized sketch file. We use abstract for version control and Zeppelin for specking and hand over to the devs, and it's really complex.
And version control is becoming a bigger and bigger issue as the team gets bigger. So now we're starting to explore a cloud based tool called Figma, which is absolutely brilliant. And we have to be incredibly careful now. There are so many of us.
So we have to run trials on new tools. We have migration plans. But most of all, the thing that has really made my life so much unbelievably improved is we've hired an amazing design operations person. So you cannot scale effectively, I say, without a design operations person.
Because they are there to remove the barriers that are making the team unable to do great work. He's absolutely brilliant, Daniel. And the other thing that he's done, which is fantastic, is kick off our design system. So, I said at the start, we were quite luckily at Babylon because the team was originally centralized, and we were all sitting together, and we could all keep a close eye on what was going on.
But then we moved to autonomous squads, and we didn't have the armature of a design system. So we decided there was multiple teams building multiple versions of the same thing, and it was incredibly wasteful. And think one of the worst things about a design system is that it's called a design system, because organisations think it's just something over there that design do, when in fact it's actually fundamental to a large company, or any kind of company where you've got autonomous teams, because it helps make sure that the work is controlled,
you don't continue to build the same things, and you're able to give people autonomy with these rigid guidelines. So, how does design systems work? Well, we have our identity, our brand values, accessibility, all our best practices. They're all held in a sort of central repository.
But the other thing that it holds is like code. So, the developers can go in and then take the code and then continue to reuse it, which makes us incredibly fast and lean. The other thing that we do is we have proper governance now.
So the teams work alone. We trust people to understand what they're working on, and they have to assess if it needs an existing component, or if they can rework a component, or if it has to be something absolutely new. If it's absolutely new, we have to go through this governance process and say, yes, this is a new component.
It only gets into the library if a second person needs it, because that's when it becomes a pattern. That leads me to process. So governance is part of our process, which has really helped us scale. It's really important to systematize process. So we don't dictate how people work, but we give constraints and guidelines to work in.
We say that everything has to start with a customer need. Everything has to be validated by research of data when possible. And we form our workers' hypotheses, which have to be validated rather than as truths. And then we try to make research a team sport whenever possible, with the developers observing regularly so they know why they're building something, which is incredibly motivational.
Then we have to pass everything through a group critique where everyone is supportively challenged to ensure that they have really worked the solution through. And then, as I said, we build on agile rituals such as grooming. The next thing I'd like to talk about is scaling culture.
I've been attacked by a small fly. Can you see that? So as the team gets bigger, this is really a significant part of my job. So we have brand values and career lodges, and this helps us give an explicit description of behaviors that will support our culture.
Everyone has a fortnightly one to one with their manager, and then we give training on how to have effective one to ones, and we use Johnny's progression app tool, and we encourage radical candor. We have a team canvas. So, like, once a quarter, we fill in this team canvas as a group.
We have an off-site, and then try and work out, like, what are we standing for? What problems do we have? Or do we all align? Does everyone understand our mission? Do we have all the same understanding of what we're working on? And as I mentioned, Radical Candor, this is a fantastic book.
It was written by a woman who was at, I believe it was Facebook, and she was struggling to give people feedback. She called this runeous empathy, where she was telling everyone that everything was fine, and actually it wasn't. She ended up having to sack the person, and she reflected on this and realized that the reason this person failed so badly is that she never actually told him what he was doing wrong.
She was never directly honest. And actually, to be a good manager, you have to have this radical candor. So you have to create this culture where people can give honest and clear and direct feedback, because that's how you have a great team culture, and you raise the quality of everyone's work.
The other thing we do is measure our team engagement. So have a tool to do this, but that can be done quite easily. I've seen people do the team, and they just take, you know, the little sticky dots, and each week so they have a map to where happy, sad, and each week somebody the people team puts the dot on on the graph.
Are they feeling happy or sad? And over time, you can see peaks and troughs and try and understand what might be causing these problems in morale. So we do this fortnightly, which allows us to continually monitor and course adjust. And I realized as when I was writing this talk that it's been replacing retros, and you know what?
I don't know if that's a good thing. I really need to think about that. That's something I should validate. So talking of retros, these are the other rituals that we have. We have Tuesday all hands, so the entire team comes in. We do it remotely.
Everyone dials in, and everyone presents their work. There's something called a visual stand up, so everyone has one minute to show the screens of what they're working on or give context. And it's a separate document, everyone can go and check it. We have shout outs, so if someone's done something particularly nice, we mention it in the shout, the stand up, and they say thank you.
So, a culture of gratitude is a really good thing to enforce. We have a gold mine where everybody, they have oh, sorry. Was somebody waving up the back there? Sorry. Yes. We have a gold mine, so people can show, like, the various kind of exhibitions or anything else that they want people to go and see.
We have a visual crit fun time where people show the different thing different work they're working on. We have this fantastic supportive critique. And then we have the Friday wins. But Friday wins, actually, it stopped working. It stopped working because there were just so many people there, and that's something that you have to continually monitor.
You have to monitor your rituals and make sure they work for the size of group that you have, because everything is constantly in flux. So part of our problem of going from six to sixty is the visibility of our work. When we started off, there was about fifteen of us in this weekly crit session, and then people just stopped coming.
And we realized that people stopped coming because it wasn't valuable anymore, And we were still working on radical candor because nobody told us that it wasn't value. Nobody told us that directly. So we realized the answer is not to force anyone to do something, but to find another option that works better.
So we broke off into tribes and then worked in quality and consistency within the tribes. You must remember that if you are scaling your team, the executives and shareholders have invested in it, and you want them to be confident that this is a wise investment.
You want to be able to move up the maturity ladder, not simply because you want to have more impact, but because the design and research are closest to the customer problem, and you want to work on things that really solve these problems. So how do you have an impact?
You evangelize, go around and tell everybody what you're doing, tell the story in a way that resonates with them, and so they understand the ROI of their investment in your team. So to sum up, here are the strategies for scaling design. Understand the maturity of your organization and make your plans accordingly.
Understand your existing team and craft a hiring plan based on what you know about them. Start with senior people when you hire, and trust them to then build the team out. Remember that what works in one phase might not work in another, so continually monitor and course correct what you are doing.
Think really, really carefully about your team structure, and then codify your practice, have career ladders, design systems, process, and that way you allow people to be autonomous within guidelines. And of course, finally, make sure your work is visible to each other and to the wider business so that you are able to evangelize what you are doing.
