Recently I gave a talk at Python Web Conf called “The Zen of Python Teams: New Lessons (for a post-COVID world)”. My goal was to revisit the wisdom of the Zen of Python and use it to encourage developers and teams adjusting to working together in our new reality. Here’s how I think it can help.
The Zen of Python Teams: New Lessons for a Post-COVID World
It’s harder than ever to focus at work. Many of us have been thrust into remote work for the first time, or are balancing work-life integration like never before. Those of us who are still working, that is. Many of us have been laid off. And if we haven’t, we know someone who has: a friend, a spouse, a relative. We and our loved ones are dealing with some pretty heavy stuff, and it all makes work harder than ever. Communication is harder than ever. Conflict seems more frequent. We’re tired and stressed.
What could I or the Zen of Python say that would possibly make a difference?
We’re all doing the best we can right now. And I certainly don’t have all the answers, I’d like to try to help. I’m an experienced engineering manager who has been leading remote Python teams for over three years. No, I’ve never faced a global pandemic before, but I have learned some solid lessons about communication and conflict, building inclusive teams and transparent processes, and improving psychological safety among engineers. And reinterpreting the Zen of Python for teams is a strategy that gives me further clarity.
I’d like to help you adopt attitudes, processes, and practices that will help you grow and be part of happier teams who deliver better software, faster. Yep: even during a Global Pandemic. I want to give you tools to improve your communication, collaboration, and productivity so that you can deliver useful software and feel successful and connected during this incredibly stressful time.
Deliver useful software? Yeah. We’re still here to do that. I believe in shipping and the positive feedback loop it creates. This quote sums it up for me, from Intercom’s VP of Engineering:
“Shipping is your company’s heartbeat. Software only becomes valuable when you ship it to customers. Before then it’s just a costly accumulation of hard work and assumptions. Shipping unlocks a feedback loop that confirms or challenges those assumptions. It makes new things possible… (and) brings life to your team, product, and customers.” — Darragh Curran
Don’t forget that a healthy culture is critical to helping engineers ship software in any environment. You deserve to work and collaborate on a team where you feel heard, safe, and respected. And in our current crisis, a healthy team culture is more important than ever. Thankfully, the Zen of Python has lots to say about healthy culture.
So let’s talk about how to build healthy, psychologically safe teams that ship, informed by the Zen of Python.
In this post, I’ll introduce and cover six of the Zen’s famous lines. While these were originally written about software development, I’m interpreting them for teams.
“Beautiful is better than Ugly”
Words like “beautiful” and “ugly” are tricky, because we implicitly understand how subjective they are. That is, they require context to make meaning, and even then we could argue about it: one person’s “clean code” is someone else’s cave painting.
Where I come from, the word “ugly” doesn’t just mean the opposite of pretty. When applied to behavior, it means misbehavin’, being disrespectful, or making trouble. My grandma would say, “Stop actin’ ugly and behave!” Do you believe behavior can be “ugly”?
Have you ever seen “ugly” behavior on your development teams? Actions taken that have caused conflict or pain? Here are a couple of things I’ve seen: hoarding information—that’s when someone knows something helpful that they could share, but they don’t. I’ve also seen bitter, cutting code reviews—when the goal should be to critique code, not cut down people.
This kind of ugly behavior makes me recall Ron Westrum’s typology of organization cultures. Westrum wrote about three types of leadership that give rise to different types of team culture and communication. His types are pathological, bureaucratic, and generative. A team’s type will be reflective in its leadership, the way it approaches problems and conflict, and the way communication flows or does not flow.
We see the most ugly behavior on pathological and bureaucratic teams. On pathological teams, information is viewed as a person resource to be used in political power struggles, and the environment is characterized by fear and threat. People may hoard or distort information, or shy from taking responsibility for their actions, because they are scared. On bureaucratic teams, folks feel more loyalty toward their immediate team than they do toward their company and its goals. They insist on their own rules, on maintaining turf, at the expense of others and the organization.
On generative teams, in contrast, the leader emphasizes the company’s mission and they rally people around that mission. They ask, how can we accomplish our goal together? People feel like they can take risks, because they feel like risks will be shared, and they won’t be scapegoated. Failure leads to inquiry rather than blame or root cause analysis.
Westrum noted that leaders set the tone for their team, but we’re all still responsible for our own actions. So ask yourself, what kind of team do you want to be on?
We could debate “Beautiful” code all day; thankfully, kind behavior is more obvious. Being explicitly welcoming, sharing information freely, and making it safe to fail are just a few hallmarks of a healthy, generative team. In the examples to follow, I’ll cover specific strategies for improving communication, transparency, and psychological safety.
Explicit is better than implicit
Explicit is better than implicit makes me think of how important documentation is. Healthy teams document their processes and expectations. 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.
Without good docs, people who already know each other can probably figure out how to get what that need. That’s because they’re sort of cheating by leaning on existing relationships 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.
Documenting our processes makes our work more accessible to people who don’t look like us, or don’t already know us. If you want a diverse and inclusive team, you’ve got to take the time to document your process.
It’s also critical to be explicitly welcoming and clear about what you value and behavior your team will or won’t accept. Write a Contributing Guide for your project that outlines what steps need to be taken to get a PR merged, or how to open an issue, how to get help, or how Code of Conduct issues will be handled. Tell new Contributors explicitly that you want them there and need their help. If you feel your team has an issue with diversity & inclusion, raise it.
Now is the time to be explicit about what you value.
Keep conversation about code in a public place, such as Slack, or on the Pull Request, is another way to lower the barrier to entry. If you use Slack or a similar tool, this means keeping your conversation about code in the main #engineering, #ops, or #feature channels, not hidden in Direct Messages or ephemeral group chats. Putting it in the open also makes it possible for anyone to learn from it, or jump in and help. This kind of documentation and transparency is critical on a remote team.
Simple is better than complex.
Developers build complicated features and solve complex requirements with sets of smaller, more straight-forward features. As humans, we build meaningful relationships and work through tough issues on a foundation of small interactions that increase trust with each other.
Small interactions like getting coffee and catching up. Talking about something other than work or code. Asking about a new game or movie you know they enjoy. Asking to pair program on a hobby project. Sharing recipes.
But wait, you say: we’re all working remotely now! The coffee shops are closed! SOCIAL DISTANCING!! There’s no passing in the hallway or catching up in the shared kitchen anymore. What are my options?
When I manage remote teams, I like to organize something called remote happy hour. Every week we meet for about an hour just to talk about our lives and get to know each other better. It’s easy and relaxing. And alcohol does not have to be involved (make mine matcha, please).
For some people it might feel tempting to skip a meeting like this one because you don’t really see the immediate value, but this kind of interaction counts as a deposit in your emotional bank account that you’re building with your teammates. You’re building that trust and that familiarity that you can lean on when things get tough. Because things will get tough.
“Here’s the thing about real work: it’s messy. It’s continually filled with trade-offs, goal conflicts, time pressure, uncertainty, ambiguity, vague goals, high stakes, organizational constraints, and team coordination requirements.” — John Allspaw
Real work is messy, and its messiness and pressure and ambiguity is frustrating and hard and painful and disappointing. “Real work” takes a real toll in the best of times, and these are far from the best of times. Let’s invest in our relationships and strengthen them. Let’s build up our emotional bank account so we’re ready when the real world makes withdrawals: when deadlines, stress, and team conflict threaten to deplete us.
Our relationships with each other are the most complex and complicated features of our lives. Like software, let’s build them with small but meaningful actions that show we care.
Errors should never pass silently.
With code, we can write more code to raise and log errors.
With humans, we have to rely other humans to tell us when we broke them.
Feedback is the tool we have to help others understand the impact that they have on us. We owe it to ourselves and each other to give timely, actionable feedback that describes what happened and the impact 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 try to improve.
We don’t let issues pass silently, because we know that letting things pass silently damages trust on teams. The pain of giving or receiving negative personal feedback is only painful in the moment, but that’s temporary. Allowing it to pass silently is something that can accrue and damage teams permanently.
Here’s a tweet I shared about how to respond to a developer who is feeling overwhelmed with shame for making a mistake. In this example, a developer approached me and said: “Oh my goodness, I am so sorry, I broke this thing, I fixed this thing, but I feel awful about it.” They were feeling shame for making a mistake.
But mistakes are normal, and I want folks on my team to feel safe to make them. I said you should respond my listening and hearing them, affirming and appreciating them, and reminding them that mistakes help us grow. I was careful about the way I responded because I love working on a team where we can be open with each other about our mistakes.
It’s a signal that your that your team is on the right track if they can talk about their mistakes. If they’re hiding, yelling “don’t touch my garbage”, that can indicate that they’re scared. But if they want to show you their trash, that can indicate that they trust you.
So be kind to people when they show your their trash. It was probably hard for them. And let’s show enough of our trash that we get so used to it that showing our trash becomes something we enjoy doing.
It gets easier for us the more we do it. And let’s be real. MOST of us have got a LOT of trash right now. Let’s work extra-hard to make it safe to share and be ourselves in this tremendously difficult time.
In the face of ambiguity, refuse the temptation to guess.
When it comes to code, refuse the temptation guess at someone’s motives. Don’t git blame and suffer quietly: you’re only gonna cause yourself more pain! When you see code that frustrates or confuses you, don’t assume that someone is actively attacking you. Humans are complex and their actions are influenced by all kinds of ideas and experience that you may never understand or have access to.
Instead, care enough to ask where they’re coming from, what they were trying to accomplish, why they took that particular strategy. Reach out and offer to listen.
And if you can’t reach out to that person for whatever reason, try to get some context from someone else who might be able to help. Put your questions on the PR, open a Github issue, address it, confront it, be assertive. Challenge directly in a way that shows you care.
Now is better than never
When I was a developer, I had a single sticky note on my monitor. It read: “Doing and being wrong is a lot better than not doing at all.”
It’s something my engineering manager told me when I was being really hard on myself. He said it because he felt like I was holding myself back out of fear of messing up or being wrong. He wanted to remind me that our team, like my development environment, was a safe place to try things and fail.
As a manager, there comes a time in my relationship with each of my direct reports, no matter how senior they are, when I share that “sticky note wisdom” with them. Maybe they’re being too hard on themselves, or struggling to get started. Whatever the reason, encouraging them to “just start” seems to help. It doesn’t matter how many years they’ve been working as a developer, or how much they know about Python.
Everyone benefits, because we all can use a reminder to start where we are. To start, and try, even if we’ll be wrong or fail. We can do this without fear that we’ll be singled out or scapegoated. On a psychologically safe team, we feel safe to make mistakes because we understand that it is part of growth. A bias to action paired with a growth mindset is powerful.
Everything feels harder than it should right now, but we all have the opportunity to start where we are. In each moment, we can decide to be a force for good: for kindness and empathy, for taking care of ourselves, and for encouraging others. Now is certainly better than never.
Thanks so much for reading. How does the Zen of Python inspire you? Let me know on Twitter.
Leading with Spoons 