 I'm introducing Kate Houston who is our guest keynote speaker. Her job title is robot emoji, crown emoji at automatic. You may know them as the company that makes WordPress, which is what we happen to use for the community blog in Fedora magazine. Kate's going to talk about dysfunctional teams. You might have some experience with dysfunctional teams, whether at your day job or in a certain community project you might contribute to. And you know, teams are just people, so it doesn't really matter if it's work or volunteer. It's still going to have some of the same dysfunctions and some of the same functions that Kate's going to tell us how to fix. And this is the world premiere of her talk, so if it's a little rough, don't worry. It's probably fine. Thank you. I love it when people introduce me like that because now you know he's set the boss suitably low, so hopefully I won't disappoint you. So my name is Kate and I am a fixer. I take teams that are struggling and I help them improve, deliver more, deliver better, and feel better about it, feel happier. But what does that have to do with your team? You know, I'm sure most of your teams are probably fine, right? No? I mean, this is an open-source conference. How do you know, though, like if I ask you how good your team is, how do you answer? And are you sure? What's your frame of reference? So in general, almost everybody thinks their team could be better, but almost everybody thinks their team is mostly okay. So what if I ask you a different question? Like, how much has your team improved in the last year? Now how confident are you? So people generally have much more confidence in how their team has improved or, you know, gone downhill over the last time period. You know, and if we think about a concrete example, like, is 30 story points good? I mean, this depends entirely on the context, right? So in teams, a lot of things become clearer when you realize that it's easier to measure progress than state. And so instead of asking the question, like, how can we be right, we can instead ask the question, how can we be less wrong? So let's reframe the question of, like, is your team good or not? You probably don't know. And instead ask the question, how do teams improve? You know, I'm just going to reduce my value under capitalism here and tell you that, like, I'm not really a fixer because there is no fixer. If you have a team that needs to improve and you want to turn it around, it takes the whole team buying in to do that. It's an adventure you go on together. So I'm really more of a facilitator than a fixer. So today we're going to talk about the four layers of team functioning. And we're going to ask four questions. So there's four layers in a team. We can think about these in terms of communication, but also these are, like, the work that we do to create clarity and agreement at each level. So mission, the why, strategy, the how, tactics, the what, execution, the deal. So the mission is the why. And it's useful at the level where it tells you not just what you do, but what you don't do. So automatic has a mission to democratize publishing, but that's much too broad for any team. So when I was running the mobile team, we would talk about making a great experience for mobile only or mobile primary users. So what does that tell us about what we don't do? Well, we don't try to make computer users happy. Maybe this is not the audience to tell that to you. On the team where now the developer experience team, you know, we talk about being a support for the entire engineering org focused on acting as an accelerant at the inflection points and teams. So there's some key words in the statement, right? Inflection point. So this is, you know, a moment of change in the team. So when we add a new hire or there's a new team lead or a new project, we want to be present and supporting them. Are we inviting ourselves to everyone's weekly meeting? Absolutely not. Another key word is support. You know, we're there to support the team. So are we there to dictate to them? Like, vehemently no. Now teams without a mission don't really know what their purpose is. And the failure mode is like analysis paralysis and kind of abdicating decisions, like no decisions can be made until we know what our purpose is. So how do you determine your mission? Well, it should be aspirational, but also kind of within grasp, you know, often the where is handed down, but you have to extract and articulate the why, you know, and craft a sentence that really captures the purpose and guiding principle of your team. How important is it? Well, the main benefit is better decision making, you know, in a certain level of cohesion, teams without a mission often spiral and spin from thing to thing. But even if you have the mission, it doesn't really help without everything else. So strategy is the how. And it's made up of proximate objectives. I'm a little bit obsessed with this term. It comes from a book called Good Strategy Bad Strategy. But the proximate objective is your like next achievable goal. So we think about the example of the mobile team. And when we talked about making what could be great or mobile, great, you know, we could break it down. So what can be great on mobile? Well, you can have a really great media experience on mobile. You can have a really great notifications experience offline is usually better. When we were working like right this year, we've been working on scaling our hiring process and like we have a number goal. But our initial got focus our initial proximate objective is to build out our capacity because it's much more tractable. Once you have that capacity, you can push on other levels. Now, strategy is the decisions that you make to deliver on the mission. If you haven't made the decisions, you can't work towards it. So teams without a strategy struggle to make decisions because almost anything can be declared to support the mission. So how do you determine the strategy? Well, good strategy requires depth and it requires breadth. It takes the context of your team, the organization, the broader world. But here's the thing. Most strategies bad. So this is from the book Good Strategy Bad Strategy. A good strategy does more than urges forward towards a goal or a vision. A good strategy honestly acknowledges the challenges being faced and provides an approach to overcoming them. And the greater the challenge, the more a good strategy focuses and coordinates efforts to achieve a powerful competitive punch or problem solving effect. Bad strategy tends to skip over pesky details such as problems. It ignores the power of choice and focus, trying instead to accommodate a multitude of conflicting demands and interests. Like a quarterback who's only advice to teammates is let's win. Bad strategy covers up its failure to guide by embracing the language of broad goals, ambition, vision and values. Does that remind anyone of anything? So strategy taken from one place won't work elsewhere. And this is actually the most common failure mode of executives as they take what it works in one place to another place. And it doesn't work. But this can be true even within your organization because absolutely everything is contextual. Now strategy is tangible and progress can be measured. You know, if we deciding to improve the media experience we could make it concrete. You know, we could identify improvements based on user feedback, looking at other best in class media experiences. We could measure it, you know, in metrics around upload and failure. Building out capacity similarly in our hiring process is tangible. We know how many interviews we conduct in a given week and we know how long everybody has to wait. Now the most important piece of strategy is what you decide not to do. Now some things you might decide not to do yet and some things you might decide not to do ever. But not deciding is deciding to fail. So you know, when you develop your strategy you look at the different ways that you might make progress against your mission and you make decisions. In engineering teams I really like theming things. So taking a group of smaller projects and grouping them together around with some kind of theme that we expect to improve. You need to understand your metrics. So what are your leading indicators of your high-level goal? You know, in hiring it's so easy because our leading metrics set people at every stage in the process. But you know, in software development it can be more complicated but you can definitely find your metrics if you spend enough time understanding them. Like how your one week retention influences your one month retention and your annual renewal. And your strategy has to fit the team that you have. You might have 10 initiatives but if you can only staff 2 then you have to choose 2. Doing everything is not a strategy. And the other thing to think about with your strategy is what would make you change your approach. So you know, you decide, you know, you commit and then you validate and you recommit. Tactics are the what. They're the concrete things that make things go. So you can also think of this as the process layer. And it makes the connection between the strategy and the work of the individual. But the tactics must be in support of the strategy. Because tactics without strategy is just busy work. You know, good process is always in service of an outcome. You know, teams without tactics can't work effectively. You know, collaboration is hard and it only gets harder at scale. So tactics are really like your team APIs that help you manage your integration points between teams or up. Now how do you determine the tactics? Well, you know, what do you need to know to be effective? What do you need to measure? And how is this problem generally solved? We really need to reinvent things in engineering teams, but we do need to be selective. Process should never be adopted wholesale, mainly because it won't be adopted wholesale. But often we can look at individual problems and find some standard ways to address them. Now developers often talk about hating process. But like, I really think the developers secretly love process. It's just when they love it, they call it culture. So, you know, instead of like, what process do we need, we can ask what kind of culture do we need to be successful, you know, and then we can try and build that culture. So how can we build a culture of collaboration? What would help? Stand up, pairing, team calls, whatever. How can we build a culture that values users? What would help? User research, support feedback. And how can we build a culture of sustainable delivery? What would help? Regular releases, retrospectives, attention to defects and metrics. So, execution is the do. Now, there's a manager joke that says if managers call people resources, they can call you overhead. Anyone had this? No? But like, the truth is that management is overhead, because everything we do is in service of people getting stuff done. Because the execution area is where progress is made. Now, without the other layers, it's just activity. But everything else without this means nothing, because nothing happens. So how do you determine the execution? Well, like, this is the easiest one. Are there people doing things? And is it clear what needs done? So hopefully, as I was talking, you were seeing how this could apply to your teams. And it's important to know that everything needs to fit together, and few teams do all of these things equally well. Now, some people only value execution, and on some level, that's fair enough because it is the foundation for everything else. But execution is most effective when it fits into a coherent whole. Now, leaders often go to what they're most comfortable with. You know, we've all met and usually dislikes the person with a new process for every occasion. But on the other end of the scale, normally also hated, is the vision person who thinks that will answer the question once they determine it normally by themselves. And this is not true. Like, the other layers need to be there as well. So I promised you four questions. Here they are. And these don't map to the layers. This is more of a grid, because you can ask these at every level. So the questions are, how can I create clarity? How can I create capacity? What do I want to incentivize? And what are my feedback loops? So there's a quote by Tolstoy that says, happy teams are all alike. Every unhappy team is unhappy in its own way. But like, honestly, I think this is bollocks. Like, unhappy teams tend to be tediously predictable. They're not delivering. They feel like victims and they're just kind of lost. So when you have a struggling question, you know, the first question is normally like, where do I begin? This is after you've got off the phone to your BFF going, what have I done? But the more helpful questions are, how do I create clarity? And how do I create capacity? So every struggling team I've encountered seems to be experiencing some kind of existential crisis about who we are or what is our purpose. You know, the mission question, essentially. But as a pragmatist, this often seems to be entirely beside the point. You know, if we're not shipping, how much does it matter what we're not shipping? How can we possibly know what we should be doing to or five years from now if we don't really know what we're doing today? So here's the thing about the existential crisis. It is comfortable. It is a team bonding experience because it usually unites them against a common enemy. Now, uniting against a common enemy is not like a team building strategy that I would advocate for. You can't deny it's like short term effectiveness. So no one in the team feels threatened by the existential crisis because it's likely somebody else's problem. And everyone can have an opinion about it because it's abstract enough that most people won't actually have to do anything. Mission debates are the bike shedding of team structure and purpose. Clarity is harder because it's much more immediate and it has to be based on what's happening today, which means you need to confront what's actually happening today. There is no hiding behind lack of vision. Our teams delivering our projects drifting on and on with no end in sight. Are we doing things because they're interesting or because they're valuable? Now, the more concrete we get, the harder it is to get everybody in agreement. You know, a wide range of opinions can find shelter in a broad fuzzy state mission statement in a way that's not possible in a narrow and clear one, the kind that will articulate approximate objective, for example. Now, clarity involves hard conversations, hard truths and defining first one, then two, then three steps ahead. It's hard work that often looks small from the outside because it's no here, no there, we're finding this, we're finding that. And it's often stating what at least some people believe to be true anyway, such as what isn't going well or what the next step should be. But it's really the most effective way I've found to get teams to stop drifting and start delivering. Now, what actions you might take to achieve clarity really depend on the team, but you might take stock of all ongoing projects as well as the purpose and timeline for each one. What's their strategic objective? Articulate the current priorities of the team, the purpose of those priorities and the rationale behind making them priorities. Clearly define the scope of upcoming milestones in every current or new project. Determine timeframes that you can predict. So you might say we're going to focus on media through the end of Q4 and you can highlight the parallel work that determines what comes after that. You might work on making sure that project status is visible and that teams have visibility into each other's work. So struggling teams also commonly suffer from a sense of overload and often this is very unevenly distributed across the team. Some people are exceptionally relaxed and other people seem alarmingly overwhelmed. If you view your team as a system, you'll see why you have bottlenecks that if they were cleared, they would increase the overall capacity of the team. So two books I really like on this are Thinking in Systems by Danella Meadows and A Beautiful Constraint. So what you might do depends on where the bottlenecks are, right? You might reduce the number of things that your team is taking on because too many people are working alone. You might take a more strategic approach to tackling inbound requests because you can't keep playing whack-a-mole. You might realign people closer to the work that they want to do and give some people clear feedback because you need people in the right, you need the right people in the right roles and they'll be that much more effective if they actually enjoy it. You might get the team to talk about timelines and try and embrace continuous delivery because having that force only comes from coming from the outside is really destructive. Now if you manage managers, improving them as leaders will always create capacity on your team. Their teams will get better. You can rely on them more and delegate to them more. And sometimes I think it feels like we don't have time to coach the people around us, but medium term, not even long term, we don't have time not to. So you can always come back to these questions because the answers change over time. There is always a bottleneck and some level of confusion is just part of the ambiguity of human communication. You need to make sure that you're not staying where you're comfortable. There's a different answer at every different layer and the question, the meta question is what is most pressing? And it's also worth noting that sometimes you do the work yourself and sometimes you encourage other people to do the work. So it wouldn't be a inspirational tech talk without this quote, which is if you want to go fast, go alone. If you want to go far, go together. And I think about this in terms of the next two questions. What am I incentivizing? And what are my feedback loops? So there's a concept of self-managing teams, which I really prefer to reframe as self-improving teams. Self-improving teams have feedback loops that make getting better over time a team effort. You know, they respond well to failure. They learn as much from it as possible. They use estimation as a better way to surface the known and unknown unknowns. They invest in collaboration that levels up individuals and the collectives. Now, the question that might emerge from this is like, okay, well, if you have a self-improving team, what's the point of a manager anyway on you redundant now? Which, honestly, I would take being able to work less than 50 hours a week. So it's an aspirational goal. But actually, I think it reframes the role of a team lead as someone who enables the team and who acts as an accelerant. And it means moving away from this need to control or feeling that the value you bring comes from the power you have. And towards having a more of a coaching mindset, you know, and the acceptance that the value you bring is best shown in the output of the team and the team health rather than anything that you actively and obviously do. Now, every new manager struggles to let go of the individual work that they were doing before and achieved, presumably, some level of mastery at. It's really hard to enter this mindset, although, you know, it's pretty easy to claim it. Many managers talk about servant leadership, which often just means that they're the dormant of their team. I call this house servant leadership and sometimes yell at people, you are not the house elf of your team. They respond well to this, it's fine. Or the other thing it means is these managers are uncomfortable with the power they have, you know, because you cannot be the servant of people that you have power over. Managers can also use this as a way, as a reason to abdicate responsibility from the day to day of their team. Like responsibility can only be a product of control or, you know, worse not even then and power without responsibility is a form of sociopathy. Now, the best leaders manage multiple, master multiple leadership styles and know when they're best deployed. When to take the hard line of the authoritative stance, when a situation is bad enough that a coercive style is necessary and when a team would benefit from someone setting the pace. They also know when to optimize for the increased buy-in of the democratic approach. When a team needs an affiliate leader to help them bond and when showing up as a collaborator will get the best out of people and when somebody needs a coach. Now, we all have our go-to, the default that we lean on, but it's not appropriate for every occasion. You know, the more that we can build out our capabilities in different styles authentically and deploy them regularly, the more versatility we have for different situations. The authoritarian leader who suddenly shows up as a coach is not going to be believed or trusted, but the coaching leader who suddenly shows up as an authoritarian is probably not going to be taken seriously. Now, the self-improving team is a place for the democratic and affiliative styles, but above all, the manager is coach and collaborator. Now, like all good coaches, you want to ask good questions and like any good collaborator, sometimes you need to get in there and provide some active help. In almost every situation, you'll get the behavior you incentivize. If you say you value feedback, but you silence dissent, you won't hear what people are thinking. If you say you value simplicity in the user experience, but you promote people based on complexity, you'll get a lot of complexity. The gap between claimed values and natural incentives is organizational hypocrisy. Being clear about incentives and rewarding the things that you want to see is key to making sure that teams are aligned. If you want to incentivize collaboration, you can't evaluate purely on individual metrics. If you want to incentivize honesty, you have to accept that sometimes you're going to hear things that you don't necessarily like or agree with or that you don't want to hear. If you want to deliver user value, you need to make sure that you recognize that work. Now, the role of a manager in a self-improving team is to ensure that incentives align with team improvement. Now, people only improve consistently if they get feedback. So, feedback loops should be one tight and two positive. This doesn't just mean feedback on what they can do better. Like feedback is just your work reflected back to you. So, it's important that people see what they can do better, but it's important that they also see what they're doing well. Making sure that people get consistent feedback and appreciation and incentive is really important. Giving people only constructive or worse negative feedback will cause them to avoid you. So, if we launch a new feature and we want to set up feedback loops around if something goes wrong, you know, like monitoring for downtime, support volume, you know, but we also want to set up the feedback loops for what we expect to go right, like usage, positive feedback. Now, the role of a manager in a self-improving team is to build and contribute to healthy, productive feedback cycles. Now, you will get what you incentivize, and it really does not matter how you feel about that. A friend told me recently about a company that was no longer celebrating promotions because they don't want people to be so focused on them anymore. And I was like, cool. If you've created that kind of culture, that celebration is probably the least of it. Now, a good team has strong and coherent communication. You know, this is a product of psychological safety, as is the ability to treat failure as a learning opportunity. They have a good idea of what can be done and how. This is how teams ship regularly. And they understand why things should be done and also why they shouldn't. You know, they make active decisions. They have aligned incentives and strong feedback cycles. This allows developing people within the team, growing the team, and creating more opportunity for others. So your team, like my team, they're probably fine, right? They can probably be bad at, too. Now, the world of open source often seems a lot messier than the world of companies. There are many things that I love about open source, but the thing that I find hardest to deal with is sometimes it feels like there's this incentive to complain and tear people down that can drown out everybody, everything else. It's like people forget that there's other human beings on, like, on the end reading their comments. And it might seem in this context that it's hard to take these ideas and fit them into the work that we do in an open source context. I think that when we remove the standard levels of capitalism, you know, we find the human aspect that much more important. You can't get people to contribute if they don't know what they're contributing to. If they don't see the markers of progress and if they don't see how to do it. So contributor events are our opportunity to remind ourselves that all software, open source software included, is built by humans. And the group of people in this room and many people outside of it are a team. So I want to think you leave you thinking about these four layers as they apply to the Fedora project. What's the mission? What's the strategy? What are your tactics? And how are you executing? And I want to invite you to ask each other these questions. How can we create clarity? How can we create capacity? What do we incentivize? How are our feedback loops? And I'll be here through tomorrow. So come and tell me your answers because I'd really love to get to know you. I'm sorry I didn't talk for an hour, but I don't think anybody wants to hit anyone and talk for an hour. Yeah, I'm happy to take any questions. If anyone had a favorite raccoon slide, we can just go back and admire it. Yeah. So I think that's where like the theming can be really helpful. Oh, sorry. So it was. Is there any advice on how to create teams? Because a lot of teams in Fedora are teams of one, which like, you know, so automatic also comes from this very open source context. And this is something like I found a lot there as well. And I think is also true of the WordPress community. So teams of one, like there is no team of one, you know, and it kind of sucks to be a team of one because you have to do everything. You're the bottleneck of the team. And, you know, if you're sick or busy or whatever, like everything just stops, you know. And so this is where I think theming is really helpful because even when you have smaller projects that, you know, are maybe just one person projects, people can come together as working under a coherent theme. And so if there's a way to group things and just declare that there will be no more teams of one and find a way to group everyone with somebody else, and then they will probably come together over time, especially if you can find more ways to collaborate. But I get that it's really hard. This is still like an ongoing thing for us at Automatic too. Anything else? Yeah, sure. We have one more question. No, it's fine. Oh, I love this question. Okay, so is there a point at which a team is too dysfunctional to continue recognizably as a team? Absolutely, yes. And if that's the case, you really have to understand why it is and probably somebody needs to be fired. Like bluntly, like, I mean, if you think about like humans in general, like especially kind of software engineers, like you, people get into this field either because they love it or they want to make a good amount of money. And I think both of these are very legitimate reasons. But like people driven by those things, like they don't want to fail, like they don't want to suck. Like people in general, I think don't want to fail. And so if you have a group of people that is failing that badly, like you need to understand why it is. And the most common reason is that there is one or more extremely toxic people who see success, you know, is tearing other people down or creating some kind of really corrosively bad environment. And so like those people need to go because otherwise you cannot have a functional team and wherever they go, they will create dysfunction until they get a lot of therapy. Any other questions? No? Cool. Well, it's great to end on that high note of firing people. Thank you so much for having me and thanks Ben for inviting me. It's really my privilege to be here.