Building Teams for Better Process, Retention, and Delivery
Building Teams for Better Process, Retention, and Delivery
This talk will walk through an approach to building and retaining teams and how to identify early in the hiring process what to look for and how to build teams based on individual, product, and business objectives.
- Planning teams to optimise efficiency and future growth
- Team focus on user and business outcomes
- Structuring teams for both empowerment and cross-business collaboration
- Key tips and insights on the hiring process
Hi everyone I'm Mike Brown. I'm going to be talking to you about building teams for better process retention and delivery. So first a bit about me. I've been working for over 20 years in design and a large part of that leading design organizations across the world but most recently in the UK for large building large in house design organizations are quite large places IBT and a Eurosport in discovery and most recently read dot code at the UK one of the UK's largest recruiters. So obviously my background and where I work are in InDesign. And in previous talks, I've spoken a lot about product design what it actually is and how we define it relates to this, and a little bit in on talking about why the product teams are here but I think it's important to come back to in product design what we asked we asked a lot of product designers now this is just sort of an example of many of the tasks that we give product designers to work on within product teams which used to be actually spread out amongst multiple roles. And that's largely the same that is largely the same across product teams now. But this isn't a problem because what I've found is that when you really kind of concentrate on these three pillars of product designs ensuring that designers can be sort of efficiently focused and enabled then you can achieve great results with all product designers across all teams. And again I think this can kind of relate to wider product teams as well. So in design under efficiency, it's just really making sure that they're using the right systems and processes and that everyone knows them and understands them. Really focused on user focus and understanding of user outcomes and business outcomes. And then making sure they enable that the product team is their first team, that's the team that they work for and that their leadership is empowering rather than prescriptive or taking down the value of the term. So really so today's talk is really about how we can kind of build from our experience obviously with a design slash but how we can build better product teams. And really looking at sort of through the planning how can we create kind of efficient focus teams the structure how can you kind of structure it to ensure that you are building sort of properly enabled product teams? And then lastly we do a lot of research around hiring and recruitment at Reed and so I'm going to share some tips from that and then how we how with everything that I've learned and how we work yet how we're building teams over at root. So to start with I'm going to start with talking about planning how to kind of build efficient and focused teams and really like to start by talking about a lot of design teams that I and some of the leaders built at BT. It was sort of quite a few years ago. It was a really exciting time. This is the first internal design organization BT had. Prior to that, they outsource almost all of their design to agencies and different departments would outsource to different agencies. But I was brought in as one of the initial hires to build out an internal capability. And it really moved much faster and better than anyone expected. So started with the initial design leader very quickly built out a relatively large in-house team moving quite quickly. This is sort of quite a while ago so we still had separations you send us designers and visual designers rather than product designers. And then in a matter of time, we kept expanding over this growth by moving away from the agency model. So other bits of design and other sorts of outcomes that were being provided by external partners and consultants were brought in-house. So we expanded the team quite quickly. And as I said it was a real sort of exciting time producing a lot of great outcomes and producing some really really great things. But then as a huge organization as a huge growing organization really struggled to measure our success.
It wasn't that while some of our designers worked in Agile processes the majority were working in sort of waterfall processes or something in between. And while we were kind of working hard it was really a lot of it focused on output, not outcomes. And really in the way that we built the team. We were constantly reacting to being told okay great. We just need this many people for this many teams we did and as I say delivered some great things. But when I look back on this, if we had just been able to plan a bit more and really look ahead a bit more we could have achieved something much more. So really what I've learned from that is it's very important to plan for growth. We grew so much faster than we expected. But that's not something that should catch up by surprise. Because if you're building a good team that's probably going to be successful and you're probably going to grow faster than you think. So what I've learned instead of a fanatic experience and then subsequent to that is that when you're planning for growth it's really important to establish a strong culture and your ways of working first. So that sounds really constant. Adding your initial hires, particularly the ones that are senior level will help you to establish that culture and that way of working. And then that will let you set the bedrock foundation which can then allow you to move quite fast. After that you can be a bit more, and you can take some more risks with later hires because you can be confident that you can train people and bring them into a strong culture and ways of working. What I found that sort of set the example in btw and then later Later experiences as well is that contractors are incredibly useful to scale quickly. So we use contractors and consultants when necessary. If we have sort of a short-term need or need to scale attendance quite quickly it's obviously the fastest way to do it. And you can get some pretty clear results if you're hiring people with a certain amount of experience with thought delivered to you. But long term this is not a great process. We found it at BT partly because of the scale of the growth. And just partly because we didn't really think about it, we've kept contractors in place for a very long time, sometimes in the same role for a long time. And the best what I've found over and over again is the very best consultants and contractors in the world behave differently to people that are full-time and working within the business within a large in a house in house corporate team because contractors understandably are thinking about where their next hire is coming from where their next job is coming from things could change at any moment. So they're very focused on their latest work and the relationships with stakeholders they're less willing to rock the boat and make a hard decision now to advance your strategy or to advance a better outcome in the future. And so while that can be great in the short term it's always important to be planning to be if you have contractors and consultants on your team you need to be planning when you're able to if they're going to be around for a while when are we turning these into full time hires when we're making these committee members of the team. And as part of that, I think it's really important to plan for progression as well. This is something that I've really learned over the years within every product team that I've ever worked in. Everyone would like to have seniors of all levels. So they would like to have senior product managers managing everything senior developers and obviously, I'm always being asked for senior designers because everyone would like to have a senior in there. But it's important to understand that in any sort of product in an organization of any size not all the work is at a senior level and it's not going to be satisfying to seniors. And it's not gonna be satisfying when you're building a larger organization to have a team of leaders and a team of people wanting to do any work.
So you can, it's important to have that balance in the team. But crucially you can plan to add some of the seniority via internal growth which is what we're doing now. And the advantage of that is it's much cheaper which is always much easier to get your business case signed off if you're not asking for senior-level NZP attention the whole time. But crucially this leads to happier teams when you have a balance in the team. When you have younger hungrier people wanting to learn from other leaders it creates a really nice balance in the team and makes overall the team teams that are happier less likely to churn and more likely to collaborate and work together. And this isn't just an abstract concept. We do a lot of research and read about employment and hiring. This is a survey that we did recently in June with 2000 active job seekers and over 250 Hiring hiring managers. And what we found really interesting is we've been talking for the last couple of years about the great resignation that with all the changes with COVID most majority of workers were looking to leave their jobs the cost of living crisis has really changed these things we're now finding that the majority people are planning to stay in their jobs. They're not looking for new roles. And what's interesting is that the main reason they're doing that is they're happy to be happy in their current role. They're worried about other factors. But why are they happy in their current role? The vast majority say because of the people it's not because of other factors. Salary is always important. But in this area, the people are the most important. And if people were planning to leave the main salaries again it's always a strong driver. We talked about that throughout this presentation. But toxic culture and poor management are some of the biggest drivers for people leaving so if you can create a happy culture it creates a happy working environment that will lead to less churn. So really how we do it read how we sort of build efficient teams really careful planning now with roles based on requirements across the entire business looking to achieve and fast growth within a team we have achieved that I've sort of been able to really increase within our sort of design organization really increase the skills and abilities across the team lead to several promotions and that's a really nice way to get to the levels you want to be internally organically. And that's just an example of careful planning Um one of the advantages is a designer that we brought in who works in marketing for our team. Previous organizations have worked with larger organizations. Quite often marketing was a separate org and not not in direct competition. But it was quite hard to get alignment between the product parts of the business and the marketing part of the business. Sometimes from a design perspective, they have separate design teams, often very separate market markers for success. And we'd often find that our designs and our experiences producing were at loggerheads. Sometimes within the same journey we'll be delivering different experiences trying to try and deliver different outcomes there was an opportunity at reed to bring more of the design in-house and actually, does that create a new role within our team that'd actually work closely with our marketing organization deliver a lot of the outcomes that we're looking for. And that's been a huge success. So one dedicated design is now producing sort of five times the outcomes that we were delivering before it's obviously saving the business a lot of money. But the biggest thing for us is it now means that we can deliver really consistent experiences from start to start to finish. For things like I'm asked for customer relationship management for our emails, we're now ensuring that all of those things are working from our design system and that all the experiences are aligned across the entire business. That's been a great outcome. And that came from looking when we were planning just outside our own area we're looking at other opportunities to work with other departments other opportunities as we're planning our planning organization planning where we want to be expanding making the business cases what are some of the areas which could add value so it's really important to look outside your own places as well. And then it's really important to have clear processes and ways of working something to really plan these things from the start and work out on them at the beginning. So we've got absolute within the design set within the design organization we have our processes and ways of working.
These are things that we've spent a lot of time working on building them collaboratively and the things that we're constantly looking to update and examine and iterate on whenever necessary. So how do we like the biggest thing as I said before to be really focused on ensuring that all the product teams are focused on their user outcomes? And that comes from really deep user knowledge and constant research we are constantly researching at reading. And we use a dedicated user research team that supports all product teams. So rather than having researchers sitting within a team we were actually sort of training and facilitating and supporting all our product teams to better conduct their own research. And it's not sufficient. And this is really useful for teams who might have less UX experience there. They have that support from a dedicated user research team. And then on the other side, we must ensure that business outcomes they're always understood for everything that we do. So we work very hard on ensuring that a company's mission, purpose, goals, and strategy they're all understood from top to bottom. It's a work in progress and something we're examining constantly. And then we have agreed with product outcomes and we're measuring them for success. And so reading on the user side that's something where we've been able to drive a huge change. In the time that we've been building up the team recently so year on year we've seen a 13 100% increase in the amount of user research that we're doing, we're now testing every week. And that ensures that every product team is sort of communicating with their users, testing with the users at least once a month, usually more than that. And more than that we're constantly measuring the value of our research. So partly we're measuring that through sort of measurable statistics like customer satisfaction and NPS but in a more direct way, we actually look at it from the other side as well. And we actually look at by testing this code by constantly researching by constantly testing our experiences before we build them we're lessening the risk. So there's just sort of one example that we had with our mobile app where we've been having customer feedback and sort of multiple customers have been suggesting the same feature they've seen in a different industry with a similar one at the Regal colour UK app. And they're asking for a feature that made sense and most people agreed. So this actually sort of entered the roadmap in the backlog and we're going to go ahead and build it. In design, we asked if we could just quickly test this experience. And to sort of find out if this was what I use is actually needed. So it is 211 to design one researcher for one day of testing with five users. What we actually found was we actually managed to find a cup we actually managed to contact a couple of users we tested with the people that actually suggested this feature to us. What we found when we actually sort of prototypes and brought this feature out is that no one used it and didn't actually solve the problem that they had. If we'd been given a suggested feature from customers which sounded like a great idea it didn't actually solve the underlying problem we found that very explicitly once we tested it if we were going to build this that would have been two weeks of wasted development. And when we looked at it we saved almost 10 times the labour involved in one day of testing so two weeks of development the number of people involved in building that we if we find these examples constantly in our weekly testing so by constant sort of user research we have sort of understanding user value you don't just add positive value you're lessening your risks and potentially making huge savings in the past not followed. And then on the business side but really we use OKRs sort of. We plan them annually, tracking them sort of weekly, monthly, and quarterly to ensure that everything we're doing can be traced back to the strategy of any large piece of work. We understand why we're doing it all feeding into our wider strategy. So now I want to talk about structure and how by structuring teams properly you can then ensure that they are properly enabled. Let's return again to the example I've been talking about for my time at BT.
So when we left the street last time we built a large team producing really a lot of work and producing great outcomes but not really in a structured or measurable way. So what happened next at the time that I was at BT was we actually brought the BT and E plus net design teams together into one huge new organization across the whole digital realm other developers or designers or product teams. At the time they took the exciting decision to move everyone on into a new agile workflow. So rather than trying to match what was happening previously, everyone in the organization was now moving into new fully agile fully enabled product teams. Now, this sort of led to massive changes for the design organization for every part of the digital organization across b2c consumers. And so if you've looked at the design organization before it obviously grew to a huge extent by adding OBIEE designers and also made huge changes to people's roles. When we did the morphology people used to be quite specialized UX designers and visual designers they all became product designers. Now, this was the right change, something that was the right thing to do but a hugely disruptive and stressful change for a lot of people. And so as part of it we did a big Agile transformation. I was very very involved in that. We did lots of training and workshop sessions to ensure that everyone had the skills to work in this new way of working produced exciting tools and all sorts of ways that we would be building up everyone into our new agile squats just some fun sort of interesting training sessions to try and build up those to the collaborative ways of working making people understand how different the ways working would be especially for a lot of people have moved from sort of agile ways of working. And then the end result was a new organization with a huge number of people on that journey into the new agile squads using sort of a modified version of the tribes and squads model from Spotify. This was obviously a huge great unnecessary change that led to immediate improvements across the board in terms of efficiency outputs and the outcomes that we're achieving. But the problem was it wasn't really ambitious enough. While it sort of made this big disruptive change we hadn't really looked enough at all the changes that might have been made. And it was mostly a rematch using the existing structure and resorts mostly driven by the number of product managers or POs that we might have not done by not really what the products needed or what the product teams would need. And what you could really see there is that while each team tended to have a dedicated product manager almost every team was sharing their other resources. So sharing product designers, developers sharing content designers, what that meant is that very few people were working on this new model we're actually focused on one product and we're actually able to keep their contexts in one place. We're constantly having to switch concept work across multiple products. And this didn't lead to the right outcomes. It didn't lead to product teams having to focus on delivering what they should be. And crucial people, they're happy with what they did and this is something that I'm aware it's been a while since I've worked at BTS. I know they've been sort of working on this model ever since and redoing a lot of what they did. So it was a good start but the structure wasn't quite right. So one thing is absolutely vital. So something that I've been pushing for everywhere that I've worked since is that the product team should always be first. So product designers need to be embedded within product teams or working from one team backlog and sort of working on continuous product discovery together. So that goes across the entire product team not just for the product designers we need to ensure that the teams are self-sufficient. And then that really comes under empowerment as well. Do the teams have all the resources they need? Do they have one? Do they have all the elements that they need to produce the outcomes that they're being asked to do? At?
We're doing quite well with that. I think we have that across the board. The one probably the exception which is the case in I think every company that I've worked in is that there's never quite enough analytic resources but that's something that we're working on as well that is something that's probably shared and could be better. But I think that's sort of a function that there are dedicated analysts who do such great work that there's never gonna be enough of them. But crucially we have to understand our teams are empowered, they are really only going to be accountable for their outcomes. It's something when we're sort of planning and structuring teams it's something that can be thought of but not necessarily followed through. And then this all ties into the leadership supportive, not prescriptive. Servant leadership is usually important in any important modern workplace to get those outcomes because the best results happen when sorting product designers. And in my experience, the best results always happen when product designers and their product teams truly only work. They're truly accountable for their outcomes. And they are the ones devising the solutions to those problems that's when you get the best outcomes. And this is not something that you can look at from the outcomes and efficiency side. Again looking at our research, this is some other researchers, so we have 2000 jobseekers and 250 hiring managers we did in February this year. What we actually found is that this is actually what people are expecting in the market as well. So what kind of manager would you like to have? People want to have to support and develop managers who are focused on people and we found a staggering 73% of people said they'd left their jobs due to poor management or bad leadership style in the past which could have been avoided. So this is something that's an ongoing problem. If there's not something that is front of mind when you're sort of building a structure in your teams this can lead to problems with retention and churn. Another point that I found is sort of really important as you're kind of structuring your team for an empowered and empowered model where teams do really have the authority and the accountability for their own solutions that can implicitly create silos within your business. Wonderful things happen when teams are really focused on their product outcomes and have the focus and the empowerment to get there. But it means that they can lose sight of what other teams are doing. You can create silos, you can create redundancy duplication teams working across purposes because they don't they're not as motivated to communicate. So as leaders as people who are planning these things it's really important to create avenues for communication. And particularly now in our lives the remote workplace. This is not sort of probably not new information for anyone watching this. But it is so much harder now in a workplace where we're currently at Reed where our entire sort of product organization is working in a Hybrid Hybrid model. So most of us are in the office for a couple of days a week and remote the rest of the time. That means that in reality, almost every meeting is a remote meeting where there might be some people in the office, some people working remotely. That means you can't rely on communication between the random meetings and the random conversations which used to happen in the office when people were working side by side and encountering each other all the time. So those things have to be created now. So obviously like dedicated cross-functional meetings in any area which is which seem to be important but then in addition to that one thing that we really work on is just sort of ensuring that we're having continuous workshops across all our product teams really evolving ourselves and other teams showcasing our work constantly and then sort of disciplining guild meetings. As much as it makes sense in your organization. These things without planning these things silos will develop and you'll lose those efficiencies from the Empowered product model. So reading what the way we worked is to try and get every team self-sufficient with all members focused on one product largely with the Lutton largely successful but something that always could have needed to be worked on.
There are always exceptions. Really working hard in that collaboration across the business plan with planning the capacity. And then another area in which we've had some great success is really focusing on our career progression framework as well across our entire organization. We have the setup for sort of engineering in our product organization in Design organizations as well this has worked and this has been really successful for our sense of being able to quickly develop people within our teams because we can sort of identify where the gaps are where they need to be working on their personal development that can develop quite fast. And then another great thing for our teams which I think leads to increased satisfaction and reduced churn is that people in our organization have a clearer understanding of what's required for the next level. So they can see very clearly where they are, what the expectations are for the next level, and what they need to do to get there. So it makes expectations very clear. And it makes progression really fair. And I think sort of within sort of reading as an organization there's a staggering number of people who've been there for a very long time. It has its advantages and disadvantages but it shows a really strong culture and a place that people will like to work for and like to remain in. So a lot last I'm just going to talk about just some tips largely from my research reading about hiring teams. We do a lot of thinking about this. We do a lot of research within sort of all industries just sort of how people are hiring and what matters to people who are seeking jobs. And for those that also sort of put the job ads out. So unsurprisingly salary is most important to job seekers. It sort of seems obvious but one that isn't always recognized. So you can see here sort of this part. This is again from our survey in February of 2000 job seekers and 250 hiring managers. What's most important to job seekers is salaries, the most important after that sort of location commute time do these things but salaries remain the most important. But despite that employers still aren't always transparent about salaries with their jobs. So 44% of hiring managers don't always display their salaries. And there are a number of reasons for that. You can see here that the reasons that people don't choose salaries are not sorted out by fighting for one reason, they have multiple reasons why they do that but also understandable in isolation. What's really interesting is that these attitudes are out of sync with what job seekers are looking for now so 62% of hiring managers think a lack of salary has no impact on applications whereas 78% of candidates see this as a really negative attribute of a job ad or a recruitment process. So it's something that though those hiring those advertising and sort of even in the way that they structure their communications in their business something that people have to realize is it's an outdated way of thinking. And it's not just a perception thing either in terms of this sort of these numbers are taken from our reader code at UK and 20. In 2021 and 2022 what we've actually found is that job ad that displays a salary get 37% more applications than those that don't. So if you're advertising roles online your advertising for your role and showing a salary will have a huge impact on the number of applications and potentially the quality of candidates that you will eventually hire. But more interesting. Beyond just the immediate benefits of salary, transparency is obviously an area that we've thought about a lot. This actually enables greater diversity which is sort of a key thing for us and for and for many companies today. Because when we don't display salary that can have adverse effects on a diverse workforce as you can see from these numbers here and crucially what the fan like when salaries aren't displayed it puts the onus on negotiation bringing the subject up if people asked to discuss and get to a scenario that led to this has an adverse effect on women over men.
And then this can contribute to a gender pay gap which is another area that is something that all companies should be thinking about. Because if there is a gender pay gap within your business or it's something that any practices are contributing to most people aren't looking at this but a significant number. But once this becomes apparent once people become aware of the gender pay gap within a business that has its almost uniform effect on their willingness to apply for a job there. So it's something that companies need to be aware of and they need to be conscious that even their recruitment practices could be contributing to this. So again just another tip from the reason pay is very important but flexibility and perks are still very important as well pay are always going to be the biggest driver when people are looking for jobs and whether they will be willing to apply for them. But what's interesting is that sort of flexible hours and other perks and benefits are very important. We did this from our research in February this year. We found even instead that similar research was done six months before we found a big difference in how important people found for extra hours that actually went down. So flexible hours were much more important six months before that. Our hypothesis is that it's not because it's less important to people but because it's actually now becoming more standard. We believe that most certainly more companies now have flexible hours. People expect to be able to work remotely people expect to be able to have sort of a hybrid or fully Remote Setup. So it's now becoming a standard feature rather than a nice perk. And so companies and employers there are. I mean obviously, we work in hybrid environments. There are some employers still pushing to have people in five days a week. I can understand them as a leader of teams. I can see some advantages in that. But I think that the reality is that most people when they're looking for a job now are expecting to be able to work flexibly and teams hiring and building businesses hiring and building teams need to be aware of this. Related to that and this is just sort of almost more of a fun suggestion at the end is continuing considering introducing a four-day working week we found when we asked the range of sort of job seekers homeowners about this 89% of job seekers are in favour of this. What's interesting is that there's been a big study in the UK testing before they work across a variety of industries across the whole nation. It hasn't been completed yet. But as they have checked in with that study and that that trial what they actually found is similar to the satisfaction here 86% of the companies who are conducting the trial I plan to continue with afterward. So far the results have been so good we're going to move permanently to a four-day working week. It's something that is obviously a sort of business-wise decision; there are a lot of things to think about. But it's certainly something that we've sort of learned from our research that could be a very powerful recruitment tool. And so lastly I just want to talk about how we hire people, that really what we look at the qualities and the behaviours that we're looking for. So the biggest thing is that we look for self-starters. So people that will obviously do our best endeavours for everything always to be clear and for through barriers that won't accept things not being right that want to have sort of an internal drive to have all the information they need and to drive and to drive for the best outcomes. And as part of that, we look for if given the choice isn't always a choice but ambition and passion are always more important to us an extensive experience. So if we can see that someone has a real passion for what they do or drive and that sort of can be demonstrated from their previous experience or even from the qualities that we can get from the recruitment process. That's something that the big driver and that's that's something that is more important than someone who has a lot of experience in a role because experience can be taught we can build up the experience we can close the gaps in the way in what people know and potentially the way they work but passion for a role passion for a job ambition to get better that's something that can't really be taught. And that's the quality those look for then this is sort of more on the design side. But I think that like all across the whole product organization, empathy, curiosity, and really kind of demonstrated ability and desire to collaborate are hugely important. If you can kind of find these qualities out and all the obvious things in there then you'll have a really strong high performing team. And as mentioned before diversity is absolutely key for both teams in the wider business. It's something that's been very clear in design organization for a while. I've heard other design leaders speak about how diverse workforces deliver better outcomes because you are getting a wider range of thought and a wider range of doing things. So that's something that we make a conscious effort to promote diversity we're trying to build diverse teams both within our current teams and across the wider organization. We think it's very important. Thanks. So thank you. Thanks very much. I hope you've enjoyed the presentation. We have a wide range of vacancies at redock. co UK for internal ones. And so if any of these jobs or any other ones take your fancy please do visit our website. Thanks very much.