Transcripts
1. Introduction: The world is evolving at a rate we've never seen before. And so to prepare yourself for that world, your team needs to evolve. My name is Dom Price. I'm the head of R&D and Work Futurist at Atlassian. At Atlassian, our mission is to unleash the potential in every team. Today, I'm going to share with you a way of evolving team practices. Building your awareness of how you work as a team, and taking action to continually improve. This is an exercise in understanding what the eight attributes are of a healthy team, so that you're equipped to understand what a great team looks like, and how you can drive improvement. The reason we're sharing this with you today, is we believe that companies and teams all over the world can benefit. Benefit from understanding how healthy they are, benefit from taking action, and benefit from out learning rituals or norms of the past, that won't help them in the future. So, one of the things I'm going to go through in this class is some action steps. From the exercises and the examples, what I hope you've got is an understanding that there's no such thing as a perfect team. The best performing and effective teams are the ones that take time out to understand how they can improve, but also to acknowledge what's working well for them. It's important to see the positives and to do more of them, and where you see challenges, pick an area, focus, take action and drive improvement. Once you do that, not only will you improve your team, you'll share your ideas and lessons with the teams around you. So, thank you for joining us. I'm really excited for the next part of the class and for taking you through our experience in understanding team health. Remember, the action is on you, so be prepared to assess yourself, your team and take actions.
2. The Future of Teams: Change is happening whether we like it or not. Being relevant and being effective is the important thing to keep your team and your business operating. A recent survey showed that 90 percent of organizations are solving problems so complex, they have to be solved by teams. Cognitively diverse teams that come together. But then you challenge that with the fact that over 85 percent of teammates don't believe that they trust their teams. So, we have this challenge, we have to work in teams but we don't trust our teammates. When we dug into this we found that the two main barriers for teammates were communication and accountability. Things that as humans we should be great at. So, how do we as teammates bring our best selves to work, so that we can help our teams thrive and not just survive? So the structure we developed we call it the Atlassian eam Playbook. Essentially, we were accidentally going down a path of building a lot of process. We were telling people what to do, and yet we realized we hire really smart people. So, what we wanted to do instead was empower them and give them autonomy to understand their environment, and to do the best work of their life. To do that we needed to create guardrails, suggestive ways of working that weren't too prescriptive. So, the team playbook is designed in two ways. The first way is, how do you understand how a team works, and is your team healthy? Then the second way is, when you realize you're not the healthiest you can be, how do you go and do exercises to get better? So, when we're looking at healthy teams we decided to do some very quick research on the back of a napkin. That research consisted of looking at three really awesome Atlassian projects, the projects where we have the T-shirts printed, the blogs, the stories, people still reminisce about the celebratory parties. Then we looked at three projects that were normally left for the closet. They're the ones that even saying the project name makes you shudder, and shake, and shiver, because we want it to look at what the attributes were of healthy teams, and healthy projects. But also things that were lacking health, that struggled, what were they lacking and why? What we landed on was eight attributes of a healthy team. We believe that a team that has these attributes in abundance is more likely to be successful. The first and most important part of healthy team is the full time owner. We then look at how that full time owner has built a balanced team around them. Both in terms of skills and explicit accountability. We then ask our teams about their shared understanding, do they know why they're doing what they're doing? Not just what they're doing. The next area is value and metrics. Do they understand the intrinsic value they're delivering? How do they measure their success? But also, how does the business measure their success? The next area is a one pager. How do you understand and communicate to the rest of the organization, or other teams what you're doing and why? We also asked them about proof of concept. How can you display and demonstrate the work you're actually doing? The seventh area is managed dependencies. How do you understand your complexity, your risk, your dependencies? He's dependant on you, and who are you dependent on? The final area is velocity. Not only how fast you're going at delivery, but how are you learning and reflecting those learnings so that you can move faster and faster as you progress. So, next we're going through the eight attributes. There's an important thing to remember here, and running thousands of these across the world, I've yet to find a team that's awesome at every area. What you should be prepared for is, there are some areas where you going to be excelling, and some where you're struggling. That's completely natural. The most healthy teams are the ones that knows where they're struggling and take actions.
3. The 8 Attributes: The first attribute is full-time owner. Who is the person that's accountable for delivery of this project? We believe that they should be 80 percent focused on this project to drive real momentum, and they should be the champion inside the team and outside the team. When you agree with this is really clear. Everyone agrees who the full-time owner is. Interestingly, it can actually change throughout the life of the project. But you know who that person is. You know the person you goes to for key decisions and for key direction. Often teams struggle in what bad looks like, when you think it's three different people. Is it Bob, Mary, or Joseph? The challenge with that is, you will often go to very different people for very different decisions, and certainly, feel like you're pulling yourself in a very different direction. This can mean that you either end up treading on each other's toes, or actually just not making decisions. So why did we land on full-time owners, our first attribute? We did it because one of the things we are really passionate about and I'm especially passionate about, is focus. How can we do less things and do them really well|? The interesting thing to remember with full-time owners it doesn't mean that's the only person doing work in the team. Every team member has an important role and every team member should be making a contribution. If you don't believe you are the full-time owner, maybe just ask the question, who is? Who is the person that you go to for decisions or debates? Who is the person that's driving this initiative and accountable? Ask that question. Maybe someone else wants to ask it as well, you never know. In terms of action plans for full time owners, it's probably one of the easiest ones to do. Grab a post it note and write down the name the person you think is the full-time owner. Then when you are ready, reveal. You'll be amazed how many different names come up. One of them might be yours. Balanced teams. This is really important for me because I want cognitive diversity. I want a variety of skill sets in my teams, so that when they come together they can really be diverse and distributed in how they approach their work. But balanced teams aren't easy. So there's a few things that we look for. First of all, do you have the right skills for the mission that you're on. Not just the right skills generally but the right mix of skills for the purpose of mission that you signed up for. The second part is is your role explicit? Are your responsibilities explicit? When it grey in teams, this is a very fluid compensation. People will know what they're being held accountable for, and they know what they are holding other people accountable for. When this goes wrong it's often because teams make an assumption. I've worked with someone like you before, and I think I know what you're doing, and I think you know what I'm doing. On day one that assumption looks fine but by day 30, we're building something completely different. The conversation here needs to be heard. My role often stays the same, but on every project team my responsibilities are different. So a couple of common mistakes with balanced teams. First of all is the notion that balance means size. At no point when we talk about balanced team do we talk about a volume of people. It's more important to focus on the right skills and the right roles. The second mistake people make is that each responsibility needs to be an individual person. You might be a one person team. You may actually have several responsibilities. So don't think about balanced team as singular people. Think about this as responsibilities that many people can have. So if you think you're struggling with balanced team, here's a really quick action for you. Give everyone a blank piece of paper, write down what you think you're responsible for and write down what you think the person next to you is responsible for. When you are finished, show them the bit of paper. Don't worry about the laughter, you're bound to see gaps and you're bound to get repeating the same tasks. Having the conversation alone is a healthy exercise. In our first session and at last in shared understanding was the area that most of our team struggled with. It's fundamentally why you're doing the thing that you're are doing and do you have trust for each other? Now trust is really important it's like oxygen. When it's there it feels fine. You only realize it's missing when it's gone. But trust is paramount to things being successful, and working together in the most effective way. When we think about why teams are doing what they're doing, what we actually found was way more of our teams were focused on what they were doing. They had a great process for execution, they had just forgotten the purpose, the mission, why they were doing what they were doing. Where you see a great team here, they are constantly using the why they're doing what they're doing to evolve, to course correct. They are seeking to understand their customer or the user. When you do that, you are genuinely building something that's going to be great for them. Shared understanding was included because we found lots of teams were running really fast and had absolutely no idea where they were running. Speed alone is not great for us. You have to have direction. We also found that we were shipping things that maybe our customers did want one day but by the time we shipped them didn't. So truly understanding why we're doing what we're doing, enabled us to be more relevant and ship more things that are used, and less things that aren't. So whether you think you have shared understanding or not, do me a favor, grab a piece of paper, maybe grab some of your teammates, and write down three words ; problem, impact, and solution. Separately write down what problem you think the team is solving. What you think the impact of that problem is and what solution you believe as a team you're building. Then share your bit of paper with the person next to you. Look for subtleties and differences. You may have the same solution, but you're solving a different problem. If you're doing that, you're likely going to build in a very different way. So have the conversation. What problem are you solving? What's the impact and what solution do you believe you're building? Value is a binary question. Should we be doing this? Yes or no. Hopefully the answer is yes if you are already doing it. Metrics are then composed of two parts. What are the metrics for you as a team? How do you know you're being successful and making progress. But what a lot of teams forget about is the second measure of success. How does my customer or end user determine whether the thing I'm delivering to them is valuable or not? We find that the best teams understand those three things. The value they bring, their internal measures for success, and how their customer is going to be impacted. We decided to include volumetrics in our A attributes because we had so many metrics. We had metrics for everything. In fact at some stages we're spending more time measuring than we were doing and I'm sure some of you feel like you may be in those teams. We wanted to get the balance between understanding progress and making progress. Volumetrics is our way of saying simply, how do we understand their value and then how do we do this in the most efficient and effective way possible? Let's talk quickly about some of the mistakes people make in volumetrics. The first one is having too many. If you're spending all your time measuring, then you're probably not making enough progress. The other one is picking the metric of the month. Every organization and team goes through phases. If you pick the metric of the month you know that it will get your project approved, but you'd also know deep down you're probably not moving that metric. So go about understanding what customers do you want to delight, and what measure can you look at that gives you confidence and the team confidence that you're having the impact you desire. So let's talk about a quick action you can take with your team. I want you to write down three words; goals, signals, measures. What's the goal of your project team? You've probably just discussed it in shared understanding. Then what I want you to do is to write down only two signals, two things that you believe are giving you an indication that you are making progress in the right direction. Then I want it to stop. Instead of measuring anything I want you to start your project. Carry on working as a team and as you do, you will start to understand what are the major success that you are moving based on those goals and signals. Keep it simple. So proof of concept. We know we've got a full-time owner, we've got a shared understanding and we know what success looks like. But we still have a million ways of getting that. Proof of concept is our way of getting a team to understand which path do we want to take. Which directions we want to go in. Which things we're going to explore and try. It's our way of understanding the value and the path of least resistance for getting there. It also helps us understand time frames, by understanding how complex the piece of work or the project is that we're trying. Great teams have a clear understanding of their proof of concept at a high level, and as they evolve, it gets more detailed. But the most important thing is, it constantly changes. Teams that struggle here tend to build a proof of concept early on and stick with it like a religion. The problem is the world around them is changed and they deliver something that the customer no longer wants. Your proof of concept should be a discussion with all stakeholders. Not only why we are doing what we're doing, but what are we doing. One of the common mistakes with proof of concept is the notion of ship and forget. Proof of concept is not a static document. It's not a requirements document. You don't produce it, get sign off and then move on. This is part of a regular conversation between the people doing the work and the stakeholders you are delivering to. To do that effectively, you need to listen as much as you talk, and proof of concept should be the document you gather around to have that discussion. Proof of Concept varies depending on the team around the environment you're in and the product or service you are delivering. But in its simplest form, the best way our teams come together is to draw a journey map. What is the journey of the end customer through this product or experience? What are the highlights and what are the low lights and what's the experience they're having throughout. When we map that journey, it enables us to understand where do we want them to turn left and where do we want them to turn right. We have to do that on purpose, otherwise they'll pick their own path and it might take them to a place that we don't want them to go to. Journey mapping truly works best when you do it in a team. What I found with the teams I work with is getting some pens and getting on a whiteboard. Drawing one line, here's the star and here's the finish. Then each contributing to where we think trade-offs and decisions need to be make. What does that user experience or journey look like? How does the flow of this experience or product fail? What we find is each different contributor has a different viewpoint and the rich discussion we have enables us to make the trade-offs of what journey we want to take our customer through. One-pager is your way of explaining and communicating to other teams around your organization, what you are doing and why. What we found is, great teams to have a one-pager because it helps them identify, who they might to be depended on, and who might be dependent on them. Also, we found that great teams when they communicate their one-pager, end up getting insights from other teams, who may have tried a similar mission. They may have been successful, but they may have failed, but they share their lessons learned. Teams that don't have a one-pager, have the same conversations, but they have it at the water cooler. So, what projects are you working on? Why are you doing that? What's the value? The challenge with that conversation is, it's instant gratification. You feel good for having the conversation. The problem is, it's hand-to-hand combat. You can't scale by having that conversation, and you can only have it with the people that you bump into. One-pager brings stakeholders from all over the world into your project, and stops them pestering you. It keeps them at arm's length, but it keeps them interested. Find a way of communicating what you're doing and why, to the teams around you. So, let's talk about a couple of mistakes with one-pager. First of all, the word one. Many teams I work with talk about the fact that they've got many pages. That's great for them, but it's not great for me as a consumer. The real test of a one-pager, is how it makes a person feel when they are consuming. So, it's not your written word. The second mistake is, I built the one-pager at the start, and I left it static. The problem is people consume that, and they make assumptions about what you're doing. But what you're doing has changed, so keep your one-pager up to date, not every day but frequently. Creating your first one-pager can be really simple. Get a blank piece of paper, and write down the value of your projects. The challenge here, is plain English. Because you're not writing it with your lingo or your acronyms, you're writing it for everyone else to consume and understand. So, in the simplest way possible, what are you doing, why are you doing it, and how you should engage with it. Once you've done that, get the rest of the team to spawn and collaborate. The best way of knowing whether it works, give it to someone outside your team, and ask them if they understand what you're doing and why. Managed dependencies is all about the execution of your project. How do you understand the risks, the complexity, and the nature of what you're doing? This is where you will need to understand your timelines. Who's doing what and when are they doing it? What's the sequence of your work? Traditionally in many teams, this is your project plan. It can be extremely simple, and sometimes it can be extremely complex. So, I want to give you a quick example from managed dependencies. Let's imagine you're the captain of a basketball team. You're dependent on the coach for broad instructions around the mission for the team for this game. The rest of the players on your team are dependent on you. What position do you want me in? What play are we going to do? When am I on or off the court? You have dependents and dependencies. What we ask of great teams when we look at managed dependencies, is do they understand their complexity and are they actively managing it? What we find with bad teams here, is they dig their head in the sand, cross their fingers and hope for the best. These are the teams that accept that bad things will happen, and they're ready to react. Great teams when they manage their dependencies, are ready to respond. They know things will change, and they have a mitigation plan in place. Being aware of your environment, and knowing that change will occur, can make you a better leader and better teammate. Two common mistakes when looking at managed dependencies. One is building a plan, and just delivering flat plan regardless. The plan you build should be an idea. It's never going to be the actual thing that happens. So, you have to evolve it. The second mistake, is everyone and everything is a dependency, and you very quickly become paralyzed just trying to manage other teams. You need to focus on delivering your work, and understanding that two or three teams, that you are genuinely dependent on. They are the ones you should be in open communication with. It's easy to get confused in managed dependencies, and try and plan everything out. Probably the best first step that I've seen teams do, is just plan out the next 30 days. Even though your approach it might be running for 90 days or 180, plan out the next 30 with confidence. What's happening when? Who do I need to talk to? What you will learn from going through those 30 days, will help impact the next 30, the next 60, and the next 90. Velocity is two things. How fast are you shipping and making progress? How quickly you learning and getting smarter? What we find is that great teams not only ship with speed, but learn as they go along. They take time out to reflect on what worked well, and what didn't, and they did more of the things that went well, and stop the things that don't. A team that struggle here, just work on a plan regardless. They move with pace, but they don't reflect on what works and what doesn't. So, they don't improve or get faster. They just ship with urgency, and not necessarily with purpose. As you work together as a team, you are naturally going to learn things about the project you're working on, and your teammates. You're going to have really strong shared understanding, and an amazing proof of concept, and great ways of managing your dependencies. But velocity is certainly different. Are you taking time out to learn what worked, what did you love about the last milestone, or the last thing you delivered? What did you loathe? What are the things that didn't work that you thought would? By stopping those things, you will move with more pace, and more direction. So, velocity is our way of achieving a shared understanding. Two common mistakes I often see with teams when we look at velocity. One is the confusion that it is simply speed, and as we've mentioned, it's not. It's speed and direction. The second one is, they take time out to reflect on what worked and what didn't, but they never invest the time in taking action. Just knowing where you're struggling is good, but it doesn't drive change. You have to take action to drive that change, otherwise your velocity will not improve. First action step with improving velocity. You need that scrap of paper again and your teammates, and you need three columns. Start, stop, and continue. What are the things that you are doing as a team, that you want to start doing? You're not doing them yet. What are the things that you have been doing, that you don't want to do anymore? They are the things that you want to stop, and what are the things you want to continue, that are working for you? The things you've tried that are delivering value. You want to double down and be more of them. The trick here is, don't add in things if you're not taking anything out. So, you have to stop things, before you add something new in. When you think about these attributes, it's easy to think that they're all static. Once I've rated them and put a tick in the box, my team is good. The challenge is, the world around you is evolving, your customers, your competitors, the work you're doing, your staff are all changing every single day. So, I need you to continually reflect. Not every day, but at regular intervals on how healthy is your team? How are you doing against the attributes? Which ones have improved, and which ones are suffering? It will change every single day. In the modern world, we're seeing more teams form and disband, and more people work across many different projects. It's likely you are in one of those camps. So, there's a few things you can do. First of all, you can use these attributes for prevention and not for cure. As you join a new team, think about the two or three areas that you want to get right up front, because they're going to have the most impact on the team. If you're joining a new team, why don't you introduce the attributes? Ask the question, are there any of these areas we're struggling with? Because you asking that question, can benefit the entire team.
4. Case Studies: So, now, we're going to move on to a few examples, real examples from teams that I've got to work with where I've learnt about the areas they're struggling with and the activities and actions they've taken. I want to give you these examples to help you take action yourself. So, we've got a marketing team in last year that run events, an event we've run for many years. So, common values where they struggled were shared understanding and value and metrics. But they were also quite successful of doing really well in a few areas. The proof of concept was really strong. They were using their knowledge and experience from previous events and rolling that forward. They also had great velocity. They were actually building a lot of momentum and taking regular intervals to reflect on what was working and what wasn't. They also had amazing managed dependencies because they'd shipped experiences like this before. They had a high level of understanding of what the complexities were and who they were dependent on. So, they had a really good plan of how to execute. So, let's dive into a shared understanding and the differences between the new team members and the existing team members. When we actually asked a few questions around this, one of the things I found was that, the existing team members, they had assumptions based on running these events before. They are carrying those assumptions with them. Some of those assumptions, in fact most of them, were true, but what they weren't doing was challenging the assumptions that were no longer true. This is where the new team members were actually in advantage. The curiosity they brought, what they didn't know, and the questions I asked enabled the team to learn together, to challenge why are we doing these events? What is the purpose? What does success look like? Having that conversation enabled them to realize that they all had an understanding but that understanding was different. So, they were going to deliver a very different experience. So those new team members weren't a distraction, they were a value add, because they asked the curious questions that we all needed to ask to get ourselves to do delivering a delightful event. So it's important to notice here team norms. Team norms aren't necessarily a bad thing. They can able you to build a lot of momentum and enable you to not challenge everything that you do and be really good at execution. But if you don't occasionally look at your team norms, you might be doing something that's no longer valuable. In this example, what we saw was a new team members by asking questions. We're able to challenge some of those norms. A lot of them stayed in this team, probably 70 percent of the norms still stuck around. But the 30 percent that we challenged and changed added a lot more value when we found a new way of working. So let's talk about sequencing. In this scenario, the team had two areas that they decided to focus on. What they actually did was decided to build a shared understanding first. In this scenario, they decided that because we appreciated that if we didn't know why we're doing what we're doing, learning a measure of success was going to be tricky. Now, that's not always the case. Sometimes, starting with measures can help you understand why you're doing what you're doing. But in this scenario, we wanted to land on a purpose. What's the shared vision of why we're doing this? Once we understood that and quite importantly in this example, it wasn't just our shared understanding, it was why we're doing this for the customers. What was the value for them? Once we had that, building strong values of metrics were a lot easier because we had that framework of why are we doing this. There's a few reasons why I chose this example and why it's important for me. The first one is the team didn't feel like there are unhealthy. They felt fine. Nothing was broken. That run the event a number of times. It would have been easy to go into war type pilot and just run again. But the investment of a one-hour exercise in looking at how they work together as a team gave them areas where they can improve. They were always going to deliver the event, but the event they end up delivering was infinitely better by having that reflective moment. The other thing I like about this example is the sequencing. Even though the team had a couple of areas where they were challenged, they didn't try and fix everything on day one. They chose to focus on shared understanding. How can we make sure we know why? Once they did that, they got back into the projects, they started work again and they paused two weeks later to double down on value and metrics. This is generally the way most teams work. You're not going to have the time to stop all your activities and assess your health and do a whole lot of workshops. So what can you do to build momentum and then how can you reflect to do the next best thing? So we're going to talk about a product team in this example, a team comprised of product manager, designer, and engineers. The team was struggling with balanced team having the right mix of skills. Interestingly, the team had been together for about three months and had been considered relatively successful, and that's because early on, the product manager was performing the role that the designer would typically play. This wasn't a gap, this wasn't a problem. The responsibilities were well within the capability of that product manager. As the team evolved and the project became bigger, that was when they realized they actually needed a dedicated designer. So what they're able to do was to make that change before it negatively impacted them. By the time they got a designer on board and that full-time role to perform those responsibilities, it was before it become a problem. The customer never knew, the projects were still delivered on time and the team was delighted with the outcomes they achieved. So when you think about balanced team, it's important to remember that a balance of the team is not static. In this example, the team that started the project was the right team. They were balanced, but the world around them change. The needs of the projects and the needs of the customer evolved and the team were able to respond to that change and re-balance. You will find often in project teams that as your stakeholders change and your customers change, you need to change the balance of the team and the responsibilities of that team. In this final example, I want to talk you through a team that was actually globally distributed. Interestingly, they were really good at shared understanding and also had a high level of confidence on value and metrics. So you might be surprised to know that they struggled with proof of concept. This came about because while they knew why they were doing what they were doing and they all have the same measure of success, they had a fundamentally different view of how to get that. Because the team was distributed, each team member was going building different solutions in a different way. Every couple of weeks, they were coming together to demonstrate their work and realizing that they were building different things. This was causing a lot of frustration, a lot of rework, and disengagement from the team. We actually solve this by doing a journey mapping exercise which we mentioned before. We got the team members on a video conference so everyone globally could connect, and we walked through what the journey was, and that's where we realized how we were all approaching this differently. The discussion then evolved to what trade-offs did we want to make. Whilst there are many paths we could take, which path where we going to decide to choose together as a team? We had the heated discussion. Once we made that decision, the momentum of that team and that confidence in the proof of concept got really high. What happened was when the teams brought their work back together, they were building something that was highly congruent that was going to delight the customer. They were way more engaged and way happier and yet they weren't building a different end product. While this isn't unique to distributed teams, in my experience I've found it is more relevant for distributed teams. The fact they are not co-located, you are not bumping into people every day, makes it easier for you to approach the problem differently. Having that conversation in advance or early enables you to waste less time, building something that's not going to get used. With these teams, we find that over communicating, genuinely making sure that you have that shared understanding, that you share this value and metrics, and that you have the same idea of the proof of concept will save you a lot of time. That doesn't mean that you won't get off track. We found that our distributed teams still struggle but these conversations enabled them to stay on track a lot quicker and prevent major distractions from occurring. With this specific team, one of the best bits of feedback actually came about three months later after this project was completed. One of the team members approached me and explained that journey mapping had become just an norm for this team, one of the rituals that they did for each project, because they knew they were distributed, they were having a conversation in every project early on around what we we were doing and why. That was enabling them to be a lot more effective quickly and to avoid that disengagement and miscommunication.
5. Putting it Into Action: What you've learned so far is about the eight attributes of the health monitor. They are the things that we do to assess how teams work together, what makes for a healthy team. The other thing we've talked through are plays or exercises, the action plans that you can take as a team to drive your improvement. Now, we've packaged both these up in the Atlassiam Team Playbook. We'd actually run with this internally for a number of years and we decided to open source it. We want teams all over the world to unleash that potential. The website you can see has the health monitors and all the players documented. That there as recipes. They're for you to try and you to explore. You might find that none of them are a full fit for what you want to do. You need to actually understand your environment and adapt all these exercises to work for you. But if you give them a try, I genuinely believe that investment will help you improve how your team works. One of the things you might be thinking about, is when is the right time and who should make the call on this. There's never a great time but there's lots of bad times. So, why don't you just take the opportunity? Find some time, grab your thing together and have the conversation. One of the things that I've experimented with Atlassian, is people rating the areas before they discuss. It stopped the celebrity in the room dominating the conversation. We actually used thumbs. Thumb up is good, thumb sideways not so good, thumb down is bad. It's a great way for the introverts and extroverts to all share their opinion, and then we have the discussion. What did you see that made you vote thumb down? What did you see that made you vote thumb up? Anything that brings a rich conversation and explores a diversity of views. I want to hear everyone's perspective, not just from the loudest person. So, let's talk cadence. How do you know how frequently to run a health monitor? How frequently should I run the exercises? It's a tricky one because it's unique to your environment. What I suggest to our teams, is never in a health monitor so often you find the same things on repeat. That's just depressing. We tend to run a health monitor at key milestones, when we have a chance to reflect. We don't want to rush the exercise. We try and focus on one or two action areas and then once we've completed those actions, we rerun the health monitor, just to do a refresh, what impact did we have. You'd be amazed at the knock on impact. Sometimes improving shared understanding can indirectly improve the one pager and vice versa. What we say to teams is, try and do these at a time when they get to prevent and not necessarily just kill. The last thing you want to do is find out something you wish you'd done a few weeks ago. So, have the conversation with your team and build excellence into everything that you do. So, your first health monitor that might feel a little bit of a struggle. It will probably take you just under an hour to get everyone's perspective, all the ratings and agree on a focus area. Don't be too upset if you don't get amazing actions from the first session. Just an understanding of where you are struggling and where you are great is a really good appreciation for the team. But followup's important. If all you do is assess your health but don't take action, that's going to get depressing. Som make sure you give yourself the time to follow through on those actions. What we say to teams is, make your actions concrete. Who owns them? How long should that workshop be? How much time do you want to invest in building that? What we find is repeat health monitors are a lot quicker. Our best teams have built them into existing rituals. Do you have a team meeting? Do you have an off site? Do you have a quarterly or monthly cadence? If you do, don't make the health monitor a separate exercise. At the start of the next team meeting, go around the room. Who's the full time owner? Do we have a balanced team? Have we got a shared understanding? Investing five minutes to do a refresh is a lot more effective than running a one hour session all the time. But only you can decide how much is the right time. So, now you've got all the resources. The action is over to you. The best way to create the feature is for us to take action today. You are a member of a team so, my challenge to you is go and run a health monitor with your team. Find out what's working. Celebrate those things. Find out what's not working and find a way as a team to get better at them. You own your future. Take the action today.
6. Wrap Up: Thank you for your participation. What I hope you've got from this lesson is a true understanding of the eight attributes of a healthy project team. Just a reminder as to why I find this important, the future of work is going to be very different from the work of the past, change is happening, technology, people, customers, competitors. If you are not changing the way you work as a team, you are likely going backwards. We want you to unleash the potential in your team, and understanding these eight attributes, and having that conversation, humans to human, can help you unlock that potential. From the exercises and the examples, what I hope you've got is an understanding that there's no such thing as a perfect team. The best performing and effective teams are the ones that take time out to understand how they can improve, but also to acknowledge what's working well for them. It's important to see the positives, and to do more of them. Where you see challenges, pick an area, focus, take action and drive improvement. Once you do that, not only will you improve your team, you'll share your ideas and lessons with the teams around you.
7. What's Next?:
Dominic Price, Head of R&D and Work Futurist
