 Hey everyone, thank you so much. It is such an honor to be here. All right, here is my flashy thank-you slide. This is the busiest slide you will see this morning. It is unattractive on purpose. It just expresses my exuberance for being here. And I always like to start with a thank you. It's really an honor to be here in this beautiful venue, in this beautiful city, full of some of my favorite birds in the whole world. Great-tailed grackles, aka Zenate. They have a beautiful story. If you haven't read their story, it's amazing. They stole the songs. That's why they sound so weird, maybe. Thank you to the volunteers, to the organizers, to the sponsors, and to all of you for coming out this morning to listen to. Let me speak. I want to talk to you about the Zen of Python teams. The Zen of Python is a collection of 19 guiding principles that influence and guide the development of the language. The lines are short and open to interpretation, and typically they're taken as direction on how we should write our code. But they also have plenty to teach us about how we organize ourselves as humans. My argument is that not only has the Zen of Python influence the design of our language, but that it's shaped and continues to influence the way we build our teams. Over the years, we've built a culture around these lines, a culture that extends beyond code into the way we live and work together. The Zen has implicitly guided us in a hugely positive direction. I'd like to get explicit about its influence so we can be more purposeful about how we want to grow and change. So my goal today is to reflect on some of the sayings and offer you a fresh interpretation of the Zen of Python buffer teams. I believe it has plenty to tell us about communication and conflict, building inclusive teams and transparent processes, and promoting psychological safety. And today, I want to teach you about some attitudes and processes and practices that can help you grow and be part of happier teams who deliver better software faster. So to illustrate these attitudes, practices and processes, I'm going to be sharing stories from my work. So I hope it's okay if I tell you a little bit about myself before I get started. I work as director of engineering at Juice Analytics, leading operations and our platform team. We use Python and Django to build what is basically square space for data stories. If you or your company has some interesting data that you want to share, our platform helps you tell an interactive story that your users can walk through and answer interesting questions in a really delightful way. And here we are hanging up our new sign in our new national office a few weeks ago. We are definitely a hands-on group. So Python has been a big part of my life for the most of the last decade, really. I've been an individual contributor on Python teams and open source projects, an organizer of Django girls. Here's a picture from our Atlanta event, an organizer of Python meetups, including PyATL, which is one of the larger ones, and a director at Django. So my stories come from my work as an individual contributor on these Python teams, a volunteer on open source projects, and most recently as director of engineering, leading and managing my Python team. So no matter where I've been or what I've been working on, I've always valued working on a healthy team. So now as an engineering manager, I ask myself pretty much daily, how can I create a better experience for the people on this team? How can I help them feel more connected or empowered or successful? What actions can I take to encourage that? In this case, it meant buying and bedazzling hats and buying themed accessories for my colleagues to wear because we separated into teams and I wanted everyone to have a nerdy theme, of course. So this talk is about the actions we can take inspired by the Zen of Python to improve our teams. As you hear me share my team's stories, I hope you'll compare it against your own experience, think about the way the Zen has shaped you and your teams, which of the saying stick with you, do any of them confuse you. When you leave PyTexas and you go back to your team, what will you bring with you? So here's our roadmap for today. First, I'm going to introduce you to the Zen, maybe you've never seen it, maybe it's been a while, so let's take a look at the text. Second, we're going to go step by step through six of the lines and interpret them for teams. I'll often start by giving an interpretation as it relates to code, but mostly I'm going to focus on reading it anew and applying it to teams. And third and finally, we're going to wrap up with a call to action to take your reflections back to your team. It's fun, it's interactive, it's my own little Easter egg that I'm excited to share with you, so stay tuned. So let's take a look at the Zen. Here's where it all began. The Zen of Python got started like so many great ideas on a mailing list. As you probably can't read from your seat, the author playfully offered up 19 lines as an outline that Guido could start from. That was Tim Peters. The Zen of Python is technically 20 lines, but the final one's left blank for Guido to fill in, but you can't actually see that, can you? Okay, here you go, a little closer. I really like how Tim used the words outline and start from. From the beginning, he emphasized how this is not complete. It's a work in progress. By its very nature and from the very beginning, it's an invitation to interpretation. So we should feel really good coming up with our own interpretations today. It's in the spirit and the spirit is joyful and playful. Let's read the lines. I won't read these aloud, but just take a moment to skim them and don't worry if you can't make it all out. So the Zen of Python came to us from the humble beginnings on a mailing list to be incorporated as a pep to be imprinted on the back of our Python shirt two years ago. It's seemingly everywhere and also right here with you. It's baked into your interpreter as an Easter egg. If you're running Python and you run import this, you can read the Zen of Python. So now that we've looked at the Zen, let's step through six of the lines and interpret them for teams. So again, we're going to take a look at the lines. I'm going to read it, focus on an interpretation for teams. So let's get started at the beginning with beautiful is better than ugly. Hard stuff right off the bat. This one's challenging because words like beautiful and ugly can be tricky because we implicitly understand how subjective and contextual they are. They require context to make meaning and even then we can still argue about it, right? Like one person's clean code is another person's cave painting and some people think that clean code isn't even a thing and we should stop saying that phrase. When I was little, the word ugly didn't just mean aesthetically displeasing. It was actually used to describe behavior as an ugly behavior as an act and ugly. Act and ugly meant misbehaving, but a special kind of misbehaving usually related to being disrespectful, particularly of adults. You need a little context of parents and kids potentially in the southern U.S. to wrap your head around the idea of act and ugly. But if you'll grant me this idea that we can act ugly, we can ask, what kind of behavior is ugly on teams? What have you personally seen done on your teams that's put your group two steps back? How about information hoarding? I think that's an ugly behavior. It defeats the purpose of collaboration and growing together when someone knows something helpful that they could share when they purposely don't share it. What about bitter or cutting code reviews? Your goal should be to critique code, not people. Or how about if somebody wants to contribute to your project but there's no information about how to get started? There's no read me, there's no docs, there's no one to ask for help. Let's break this down a little bit more. To help interpret the lines for teams, I want to introduce you to Ron Western's typology of organizational cultures. He wrote a paper in 1988 where he identified three types of leadership that bring about different types of culture and team communication. Those are pathological, bureaucratic and generative. Your team's type is going to be reflected in its leadership, the way it approaches problems and conflict, and the way communication flows or does not flow in your organization. On pathological teams, information is viewed as a personal resource to be used in political power struggles. They're characterized by large amounts of fear and threat. People often hoard information or withhold it for political reasons or distort it to make themselves look better. Sounds pretty ugly to me. On bureaucratic teams, alignment with one's own unit or function takes place of alignment with the mission. They protect departments. There's an idea that they want to maintain their turf. They insist on their own rules. They want things to be done by their book. Sounds kind of imperious, kind of authoritarian. When you're working on teams, that's not a good look. Someone call it ugly. On generative teams, in contrast, the leader emphasizes that the most important goal to accomplish is the mission and they work on rallying people around that mission. They ask, how can we accomplish our goal? Those groups tend to be higher in cooperation. People feel like they can take risks because they feel like the risks will be shared and they won't be scapegoated. And failure leads to inquiry, not scapegoating or blaming or root cause analysis. Information flows freely. Hey, I think we found something beautiful. So behaviors on pathological and bureaucratic teams hold your team back and they're ugly. But if you can get it right, if you can build a generative team, you'll be rewarded with a happier team that'll deliver better software faster. That's beautiful. So ask yourself, what type of team do you want to be on? We could debate beautiful code all day. Thankfully, beautiful behavior is a little more clear. Next up, explicit is better than implicit. It makes me think of how important documentation is. Is Mason here? Did anyone see his amazing talk yesterday? Yes, it was so good. Mason is the undisputed Docs evangelist of Pie Texas this year and I'm going to give him some more reasons to preach the gospel in this section. Healthy teams document their processes and expectations and how tos. They provide playbooks and resources and onboarding guides and tutorials. They make it clear how to contribute, what steps to take and what to do when you're confused. They do this because documenting your processes makes it easier for others to join you. Now, without good Docs, as I think Mason alluded to yesterday, people who already know each other can mostly muddle through. That's because they're cheating and they're leaning on the existing relationships they already have to get unblocked and get their questions answered. But what if you're a new person, you don't have that shared context. You don't know the back channels. So we need to document our processes in order to make it more accessible to people who don't look like us or don't already know us. Along with public Docs, it's important to keep conversation in the open. Another way to lower the barrier to injury. If you use Slack or something similar, this means keeping your conversation about your work in the main channels, not in DMs or other obscure places. Keeping the conversation in the open makes it easier as we see here for anyone to learn from it or to jump in and help if somebody has questions. And while Slack is not documentation, keeping your chats in the open does create that public record. That is somewhat searchable, depending on how you feel about Slack's search feature. Documenting your processes also improves relationships between teams. This is some of my team, my boss, one of my leads, one of my other leads. Healthy teams head off conflict by setting ground rules about how they communicate with other teams. On our team, one of our values is consistency of process. We have several types of SLAs or service level agreements with our customers, both internal and external, where we have to be crystal clear about how work will get done and on what timeline and who's going to work it. Before we wrote these SLAs, our inner team relationships were pretty strained. But once we took the time to document our processes and expectations, we found we had way less conflict and more mutual understanding of what it was going to take to get the work done. So that meant fewer fire drills, fewer late night requests, fewer people working on the weekend and starting to feel bitter about that. We also document our people. Recently, I put a call out on Twitter to ask about y'all's favorite lines and I really love this response from Lee. Lee is referring to code here. But we can do this with people too. On my team, I led us in an activity where we created individual profiles to share amongst our team. The profiles answer some of the following questions. And I asked that my folks refer to these pretty periodically, especially before working closely with an individual. Because the doc can remind us how our colleagues know they will feel successful and what might cause them to stumble. It was a fun activity. I'm going to be giving a whole talk on the process that led to these documents at Lee Dev, New York in a couple of weeks. So watch that talk or chat with me if you want to know more about that process. It's more involved than this slide, but trace. So in the next one, simple is better than complex. We build complicated features and solve complex requirements with sets of smaller, more straightforward features. Right? That's how we do it. We build meaningful relationships and work through tough issues by building a foundation of small interactions that build emotional bank account or trust with each other. So make sure you're taking the time to have coffee with your colleague or catch up on the weekend or ask questions about each other. Show you care personally. You don't have to be a manager to do that. You spend most of your days with these people. On our team, we're mostly remote. So we do something called remote happy hour. Every week we meet for an hour just to talk about our lives. We just grab a beverage and chat. And I think for some people might feel tempting to skip a meeting like this because you don't really see the immediate value. But this kind of thing is what helps you make a deposit in the emotional bank account that you're building with your colleagues. You're building that trust and that familiarity and that shared language and those good feelings that you can lean on when things get tough. And sometimes your colleague with a pug puts on a pug mask and you get to laugh a lot because he totally confuses his pug. It was pretty great. Yeah, Casey, Casey rules. So it's important to make make this time a priority because, you know, it's not always pug masks and giggles, right? Like, we're going to have to make some withdrawals from this bank account. So let's make sure it's healthy. Deadlines and stress and team conflict is going to take its toll. Someone's going to frustrate you. They're going to annoy you. And so our relationships with each other are the most complex and complicated features of our lives like software. Let's build them with these small deposits that show we're here and we're invested. When I asked my team which line of this then they like best, one of my ops engineer said this one. Makes sense, right? He's a good ops engineer. If something goes wrong, people want to know he loves this line because he says something's wrong with my code. I want to know. Interestingly, in the very same week in another conversation with one of my direct reports, a developer said, if I hurt someone, I want to know. With code, we can write more code to raise and log errors. But with humans, we have to rely on other humans to tell us when we broke them. And feedback is the tool we have to help others understand the impact that they have on us. We owe it to ourselves and to each other to give timely actionable feedback that describes what happened and the impact that it had. On a healthy team, if someone screws up, they shouldn't feel like they need to hide it or from it. We understand that people make mistakes and feelings get hurt, but we value each other enough to take responsibility for our actions and improve. We don't let things pass silently because we know that letting things pass silently damages trust. The pain of giving or receiving negative personal feedback is only painful in the moment, but that's fleeting. Allowing it to pass silently is something that can accrue and damage teams permanently. The other day, I tweeted about how to respond when you wake up from a call with one of your... You wake up to a wall of text from one of your developers who's like, oh my goodness, I broke this thing, I fixed this thing, I feel so terrible about it. And I said that you should respond to things like that by hearing them and affirming them and appreciating them and reminding them that it's okay to screw up. I was careful about the way I responded to this because I really love working on a team where we can be open and vulnerable with each other about how we feel. It's a signal that your team is on the right track if they can talk about their mistakes. If they're hiding, if they're yelling, don't touch my garbage, that can indicate that they're scared. But if they come right up to your door and they say, I wish I had a trash bag as a prop right here, look at my trash. Look at my trash. Oh, my beautiful trash. That can indicate that they trust you, right? They're not scared. So be kind to people when they show you their trash. It was probably hard for them to show you their trash. It gets easier for us the more we do it. So let's not let our errors pass silently. In the face of ambiguity, refuse the temptation to guess. When it comes to code, refuse the temptation to guess at someone's motives. Don't get blamed and stew about it. You're only going to cause yourself more pain. When you see code or behavior that frustrates you, don't assume the worst. Humans are complex and their actions are influenced by all kinds of ideas and experience that you may never understand or have access to. So grab some time with them and care enough to ask. Ask where they're coming from. Ask what they were trying to accomplish. Why they took that particular path. Offer to make them a cup of coffee and chat about it. If you can't get blame and reach out to that person for whatever reason, try to get some context from someone who might be able to help. Put your questions on the PR, open a GitHub issue, address it, confront it, challenge directly and care personally. Refuse the temptation to guess. I really love this reflection from my lead, Magna, on why this is one of her favorite lines. And I think it works for people really well too. It can be really tempting, sadly, to explain away people. Oh, she's just a grumpy old assistant man. She doesn't get it. She'll never get it. Or he's in sales. He doesn't care about how the code works. Or, you know, they're new and they don't... I just don't think they're going to deliver this feature in time anywhere close to time. It can be really tempting to explain away people in these ways. But if you set really clear expectations and give clear guidance and have good documentation and show that you care personally and make it safe to fail, then people will just exceed any expectations you ever could have had for them. And one final note for the managers in the room. I really tried to keep manager-specific advice in this talk to a minimum, but I think this one's important. Your weekly one-on-one time is your time to beat the guessing game. Don't guess about your direct reports. Just use that time you have scheduled to ask open and meaningful questions about the things that matter, about what's motivating them, about what's frustrating them, about how they'd like to grow. Just use the time. So this...it's time for the last line of the Zen that we're going to focus on today. And what better time for the line is? Now is better than ever. Developers of all experience levels can get tripped up over thinking their work. Sometimes in the process of trying to figure out how to be the most efficient, we can be vastly inefficient. Now is better than never reminds us of the value of taking some action, however small, to move closer to our goal. It's oriented towards doing. Doing, even if we end up being wrong, because doing gives us information. When I was a developer I had a single sticky note on my monitor. It's something my engineering manager said to me in a time when I was being really hard on myself. Doing and being wrong is a lot better than not doing at all. He said this because he noticed how hard I could be on myself and how doubting myself was really holding me back. He reminded me that our team, like my development environment, was a safe place to try things out, not meant screwing up and breaking things. Sticky note helped me through some hard times as a developer and now it helps me as a manager. There comes a time in my relationships with all of my direct reports, no matter how senior they are, that I share the sticky note wisdom with them. I share it when I feel like they need it. Sometimes they need to hear this because they're being too hard on themselves. Sometimes they need to hear it because they're just having a hard time getting started. The cool thing, everyone's needed this wisdom at some point. It doesn't matter how many years they've been working as a developer or how much they know about Python. They always need to hear this at some point. That's because everyone benefits from feeling like they can just start where they are. On a psychologically safe team, people feel safe to make mistakes because they understand it's part of growth. There's no fear that they'll be singled out or scapegoated. On a healthy team, people seize the now. Comfortable that they'll never be perfect. So there you have it. Six things from the Zen of Python, interpreted for teams. I hope it's been useful to you. I hope you've been thinking about the teams you've been part of, how you'd like to improve and strengthen them and how the Zen inspires you personally. Because if you have been thinking about these things, then you're ready for the third and final section of my talk, the Easter Egg. Volunteers, this is your cue. Yes. The Easter Egg. The Easter Egg. The Zen of Python is itself an Easter Egg. So it just made sense that my talk would have an Easter Egg too. Right? Pi Texas volunteers are now coming around the room with something special for you. Thanks Pi Texas volunteers. Y'all rock. Yes. So we know that the Zen of Python is itself an Easter Egg. And we also know that the final line of the Zen of Python is as yet unwritten. And we remember that the Zen of Python started on a mailing list in a spirit of playfulness and joy. And let's see what we can do with this and open to interpretation and an invitation to interpret it. So my challenge to you as you pop open your egg is to write and share the 20th line of the Zen of Python. You've been thinking about your teams. You've been thinking about what inspires you, what challenges you, what you'd like to do better. You're ready. You're ready to write the 20th line. So inside the egg you're going to find some directions I want you to write a phrase that you want to bring back to your team. If you can hand write it, that's awesome. There's something that happens in your brain when you make the pen or pencil move with your hand. But you're welcome to type it out too. But just write something that you want to be reminded of or something you'd stick on your monitor or something you'd tell someone new. Write something that'll make you smile. Write something that'll challenge you. Write the 20th line of the Zen of Python and then share it. Post it on Twitter. Use our conference hashtag. Use the ZOP20 hashtag. Take a picture. Drop it in your team Slack channel. Tag me if you'd like. I'd love to see. Tag juice analytics. We might make a data story with it. I'm really excited to read what you're dreaming about. What's challenging you and how you want to grow. And I'm thrilled for the teams that you're part of. Long live Python. Stay in touch.