Zen of Python Applied to Management
If you’re not familiar with it — there exists a document outlining the “Zen of Python (PEP 20)” — it is a document written by one of my idols, Tim Peters, and outlines:
“Long time Pythoneer Tim Peters succinctly channels the BDFL’s guiding principles for Python’s design into 20 aphorisms, only 19 of which have been written down.”
While tongue-planted-firmly-in-cheek, it’s actually been a good set of guard rails for core python design and implementation, influencing most Python projects out there. As my friend Jacob Kaplan-Moss put on twitter:
jacobian
Much of the Zen of Python applies to management nearly as well as it does to programming.
9/26/16, 11:58 AM
I’ve felt the same way for a long time. As a leader and someone with a programming background (see my post on my journey from individual contributor to leadership). Going into management/leadership I found more and more the Zen of Python applying not just to what “beautiful code” looks like, but also to management structures and leadership (e.g. a useful mental model).
As with all things, they are intended more as guideposts than hard rules. But let’s run down the list. In each I’ll point out why it applies/doesn’t apply and maybe even some examples of companies that have Done It Right in my book.
Beautiful is better than ugly.
Obviously this is fairly subjective — and a lot of people spend a lot of time trying to define ugliness and other aspects of this. The way I see it is really simple: user experience comes first. This means, in leadership that you should be focused on the end user at all times. It doesn’t matter who your end user is — paying customers, other developers, or internal users — tools, processes, and interfaces should not fall prey to Conway’s Law:
“organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations”
Lets use the “internal people are my customer” for a moment — what is beautiful vs. ugly? What do you expose?
When you look at users, you can assume that they:
- Don’t care/know about your internal org structure or communications systems.
- Really don’t care about your internal processes.
- Do care about getting meaningful things done.
The same applies to people management. A developer on my team doesn’t want to know how the HR / Budgeting sausage is made; instead they care that they have a career path, a mission to align to, and security. It’s my job to insulate them from as much of the sausage making process as humanly possible.
Beautiful is a focus on the end results, and abstracting away things people don’t need to care about. To do this requires understanding what drives and motivates people, and who your user personas are.
Sharing is caring, and while it’s cool and context is everything, sharing too much, being too ambiguous or falling prey to Conway’s law demoralizes people and hurts your users and your team. It turns you from beautiful to ugly very quickly.
Explicit is better than implicit.
I could literally write thousands of words about this (I have) but I’ll try to keep it short. Just like API contracts in code, management’s duty is to make implicit norms, values, plans, etc explicit. Your job as a manager & leader is to strip away ambiguity. How do you do that?
WRITE SHIT DOWN. Did you have a meeting/all hands where you talked through a deck? Great, take meeting notes and write it down, and send an email linking to those notes. I guarantee people only absorbed one or two ideas. Committing to plans, roadmaps or features? Write it down. Write it down publicly and make it easy to find.
The long and the short of it is to communicate often, broadly, and in a non-ephemeral form. This means not using slack, IRC, etherpad, or google docs as the Plan Of Record for anything: not your org structure, meeting notes, career planning or advancement for your people. Put it down someplace permanent.
Also, the kicker here is you have to make your communication expectations explicit and write them down. By far the best way I have seen this done is by GitLab in their team handbook, which I have cribbed from and adapted for my team and others at work. GitLab does a fantastic job of clearly defining what, where, and how to communicate effectively. It’s also published online so it’s available everywhere (e.g. not buried in a PDF on an intranet) and anyone can submit a pull request to improve it.
More importantly, as I have said elsewhere, they (GitLab) publicly and explicitly share their company values — it is unambiguous (unlike some mottos/values like “Do the Great Thing for Success”). Quoting myself on unwritten rules, assumptions and norms:
What I mean is this: no more unwritten rules or expectations. No more assumptions that we’re living in a utopian meritocracy. We don’t. Sure, OSS has been defined as “they with the best code and who does the work, wins” — but that ignores the frequent corollary of “those with the thickest hide, and ability to fight win”. Look at any mailing list — look at the discussions on the relative merit of a given feature, bug fix, etc. You will see things that would make your hair turn grey. You will see people shouted down for naivety, you will see that even the most meritorious idea may not win against the establishment.
This happens everywhere. This is why I say “explicit is better than implicit” when it comes to social norms and expectations.
This happens in the workplace all the time; if you don’t make it explicit and enforceable, then those with the highest political awareness / ability or those with the loudest voice will always win. Your job as a leader is to give a voice to those who do not have one, bringing everything you can out of the shadows and into the light.
If you’re not destroying ambiguity, you’re not doing your job.
Simple is better than complex.
Let’s look at this purely through the lense of management, organizations/etc — how easy is it for team to collaborate? Does an individual contributor know who their boss is? Do they have the ability to quickly look outside of their team and understand who does what, where and how to get things done?
This doesn’t mean that you should go full Zappos (lol holacracy) in your organizational structure, or hyper-deep on VPs/Directors/Managers — it’s a balancing act. Bureaucracy will grow to fill the void if you’re not explicit and organized in the most simple of ways.
Meanwhile if you go full Zappos flat org/no managers/lol meritocracy/holacracy/etc you’re probably looking at the scene for Lord of the Flies Part 2: Corporate Jungle.
Everything should be discoverable and understandable — remove jargon, publish and communicate widely. Ensure your organizational structure doesn’t end up with “dangling managers” (managers with maybe 1 direct and 100000000 people above them).
Complex is better than complicated.
This is perhaps my favorite one — you might be thinking that complicated and complex are the same? Nope! Complicated is: “difficult to analyze, understand, explain, etc” while Complex is:
“composed of many interconnected parts; compound; composite:a complex highway system.”.
The key here is “difficult to analyze, understand and explain”. You can have a company of a billion people and still have a complex, but not complicated system of interacting and collaborating. Your organizational structure shouldn’t be complicated, but it can be complex if it has to be (see the next one). The deciding factor is that it shouldn’t take a 3 hour meeting to tell people where and how they fit into the world, what the mission, vision and values are and how they fit into them (this is why I like Google’s OKR system for goals).
All of this applies to collaboration and cross-team work. Think back to my point about “beautiful is better than ugly”. You can have a complex system within your organization, but it should not be complicated to collaborate. For example, if I have to go through 15 layers of management just to work with you/get approvals, it’s more than likely I’m going to work around you.
This of course doesn’t win me any popularity contests. But seriously if I can’t figure out how to order a new mouse in under a minute I am so going to buy it off Amazon.
Flat is better than nested.
Please, please please please please.
Ok, I’ll stop begging about flat organizational structures and clear lines of ownership. Now, to a certain point, flat doesn’t work out great — for example, I personally believe that a front-line manager taps out at around 9–10 directs. Why? Because — time, attention and career growth.
Just think about repeating one hour one-on-ones — 10 people is 10 hours out of every 40 hour work week. Not to mention, how do you handle doing meaningful reviews for 15–20+ people? How can one person know what they want, what drives them? And how can this person be expected to have enough time to go do anything meaningful about it during a regular work week?
But back to the point about flat versus nested orgs. I kid you not, I was once in a meeting (years and years ago) where we were a small company getting swallowed by a big one. The atmosphere was tense, and people wanted clear answers and to just get stuff done and then the HR-someone started speaking.
I think I checked out about twenty minutes into an hour long “deep dive” into the organizational structure. I might have started drinking, all I know is I just blacked out.
It was insane, and while tracking us back to a CEO-who-we’d-never-meet’s ancestors was great (think they may have actually covered literal ancestry stuff), it didn’t really help us understand who to talk to, who to escalate to, or how to get things done.
Remember this (replacing user with employee):
When you go back to the employee you can assume that they:
- Don’t care/know about your internal org structure or communications systems.
- Really don’t care about your internal processes.
- Do care about getting meaningful things done.
Point 3 really is the key here. If your organizational structure is multiple managers, senior managers, directors, senior directors, vice presidents and senior vice presidents deep, you may have a greater love for diagramming tools and hierarchy than people. Hierarchy when done well, is simple and clean, otherwise it’s nation building, turf wars and craziness.
As a leader, try to keep it flat and sane. I remember once having a free form unofficial one-on-one with someone three business units over. Apparently, they mentioned it to their boss over coffee. I soon had that manager, two directors, a VP and some other people berating me for undermining the hierarchy.
I was just trying to see how someone was doing, how they were feeling, and if they were engaged at work and to offer them help. You know, mentorship.
Sparse is better than dense.
I’m going to solely focus this one on the idea that a single manager, HR business partner, etc can’t scale up to dealing with 15, 20, 50, 100 people. If you have that level of organizational density and communications, you’re screwed. Why? See above! With a team of 20 people directly reporting to you, you’re on track for 20 hours of one-on-ones. You’re on track for annual reviews that take months. You begin to forget people’s names and what drives them.
You end up delegating getting things done to other people (“leads” otherwise known as unfunded managers). You lose touch. Or you sacrifice your boundaries, and those of the people you lead and your family, on the altar of density.
Sure, different people scale better in leadership roles especially if you scope them to nothingness — but packing people deep like cattle in cattle cars means you end up sacrificing human touch, empathy, you can’t connect people to the mission, and vision.
Now, I do know that in some places managers are literally just scale/fan out/mechanical mode — technical leads rule the roost and managers are really human resources people. That’s ok, just not my ride.
Remember, your job is hacking people. You can’t do that if you don’t have the time.
Readability counts.
This hits on explicit and implicit and communications. You communications should be simple, concise, lacking jargon, and discoverables. Go back to the GitLab communications and values parts of their handbook. Part of making things explicit is making them readable, understandable, relatable. Don’t bury things in PDFs and powerpoint decks with jargon such as FNBF LOL DDN (I made those up), or cute code names for everything.
“Hey have you heard of project Sparkle Shine?”
“No, is it a NSA spying program?”
“No it’s our new identity management system”
“Why not call it that?”
“…”
(Actually in all seriousness, I think the NSA should use My Little Pony Friendship is Magic names, it would make me feel better about my IoT toilet spying on me.)
Also jargon doesn’t really save you the time you think it does — in fact business jargon excludes people, is pretentious, and confusing. What does “double click on that” mean outside of the context of a button?
“Let’s double click into that to open our kimono to identify key synergies in our intake processes.”
That’s not readable. That’s not even English, it’s like leadership elvish.
Special cases aren’t special enough to break the rules.
Let’s face it, rules are rules. Very frequently in business and leadership those rules are designed to keep you out of jail, from getting sued, and to protect your people. Things like sexual harassment, insider trading, and other things are serious business. HR rules around what’s OK to ask in an interview and not, etc are there to protect candidates and possibly remove systematic biases.
Your culture isn’t so special that you get to break the rules, asking about someone’s sexual orientation or if they’re pregnant or have a mental illness. You are not special. The rules are there to protect people; yourself included.
Be careful though, don’t mistake guidelines for rules — like compensation or promotions. Some leaders read the guidelines and those become the rules, when in reality they’re guideposts.
Although practicality beats purity.
This is my point about confusing guidelines vs. rules. Leadership, HR, Legal all have to be very, very, very clear about what is a rule, versus what is a guideline. For example, your HR and compensation department have guidelines about pay bands, compensation and things like that.
They also have boilerplate job postings that require random college requirements and a decade of React experience.
These are guidelines, and practically speaking if I need to break them to hire or retain people, I will. I’ll break them at the speed of light ,and fight to the death to defend my people. Same goes with “intake processes” or whatever process you do to collaborate with teams, heck, to some extent even organizational structures.
Remember PEP 8:
“A Foolish Consistency is the Hobgoblin of Little Minds”
Remember though, you have to be explicit about rules versus guidelines. New manager, employees, leaders of all levels will see/read/hear something and accept it as a Rule Not To Be Violated, and that hurts everyone.
Errors should never pass silently.
Also known as “pointing out the damn elephant in the room”. First, if your user experience internally and externally has become a FEMA site covered in Conway’s Law, you need to step up, call it out, and get it fixed. I don’t care if you’re a VP, if you have to grab a mop to help clean it up, do it.
More importantly though: let’s talk about passive aggression, subtle and not so subtle harassment and other things.
Your job, everyone’s job, is to give voices to the voiceless. It also means that as a leader you shouldn’t let “little shit” pass. For example, being aware of passive gender slotting like “well she’s a girl; she can take the notes”. They may not say it aloud, but it’s a pattern and you have to call it out in the moment.
Or when someone on the team makes an inappropriate joke, or statement — you have to stop and explicitly say “that is not cool, period”. It’s your job to call things out so they don’t slide and become systemic, and the people being mocked or marginalized can see that you, as a leader, are standing up for them.
If you let toxic people rule the roost, instead of raising that error and dealing with it, you have failed. This also applies to toxic leaders above you in the organization. Call it out and deal with it in the moment, don’t let it slide.
You want to assume “positive intent” — but people are fallible and they have blind spots or behaviors they’re not aware of, and so they can make mistakes. Generally speaking, they’ll appreciate you helping them stop bad behavior. If it’s a pattern, and consistent in the face of calling it out and providing feedback, deal with it. That’s your job.
Unless explicitly silenced.
“Explicitly silenced” in a leadership / organization is either when you have been executively overridden on fixing a thing (nuclear intervention).
On a people level well… as a leader I hope you know what explicitly silencing toxic people entails.
In the face of ambiguity, refuse the temptation to guess.
Brene Brown has done a lifetime of work discussing this in a personal/leadership context. There are times at work, in a leadership role, or as an individual contributor where there will be ambiguity. I’d suggest reading “Daring Greatly” where she dives into the “stories we are making up”.
Given a lack of information, context, or awareness — nature finds a way. Or, more to the point, people fill in the gaps. If you’re not giving them feedback, they’ll assume the worst (they don’t care about me I’m about to get fired). If you, as a leader, aren’t communicating, they’ll assume the worst.
It’s up to you to not fall into this trap; accept ambiguity and lead through change. Don’t assume a quiet employee is going to quit: talk to them. Make it explicit and clear.
There should be one — and preferably only one — obvious way to do it.
Duh. I mean literally, if you have 180 bug trackers, and 300 ways of ordering a mouse, guess what? FIX. YOUR. SHIT.
If people looking to work with you suddenly encounter a ten headed hydra, they will work around you. This goes back to making stuff explicit and communicating it. Same goes for user-facing stuff. Don’t force your customers to use $N systems just because your organizational structure looks like $N. Don’t make them revert to executive carpet bombing for customer service.
You don’t need to force everything into one thing, nothing is that complete, but at least get it down to one or two well defined paths and processes. Otherwise you’re burning money and pissing off your employees and customers.
Although that way may not be obvious at first unless you’re Dutch.
Being of Dutch ancestry, I can admit that this is true.
Now is better than never.
Also known as “Perfect is the Enemy of Good”. Or “doing the hard thing about hard things” — there is no perfect solution, or time to do hard stuff. Do it, get it done, and move forward. Otherwise, projects languish, people feel scared and confused, and worse.
Just get it done.
Remember though, you have to be mindful of people who need time to think, accept and reach a conclusion. Don’t steamroll them just to get it done. This requires an understanding of people strengths and personalities so you can tell who is still in “thinking” mode.
Although never is often better than *right* now.
Simultaneously true — if given a choice between say, shipping a crap product to customers just because of sunk costs right now, and not shipping it, guess what?
Don’t.
If given a choice between promoting a toxic person or letting them quit? Well I for one am not a fan of lending more authority to toxic people. Never works for me, even if there is an urgency around that person leaving.
If the implementation is hard to explain, it’s a bad idea.
I hope you read the part about complex versus complicated. If your thing requires a handbook, plus an on-ramp meeting and constant high bandwidth explanation, you did it wrong. If your organizational structure is a gordian knot of “matrix organizations” and people, you did it wrong.
Hard to explain is the trick to know if something is complicated (bad) or simply complex. Same thing with compensation structures, reviews and one-on-ones. Keep it simple.
If the implementation is easy to explain, it may be a good idea.
Well yeah, thanks a lot Tim. :heart you:
Namespaces are one honking great idea — let’s do more of those!
Ok, I’ve got nothing. Maybe some things are only applicable to code.
Wrapping it up
This was a bit of a fun exercise after writing about my journey into leadership. As well as my posts on boundaries and everything dying (identity). You can see a theme emerging — what I’ve learned and how I’ve grown, but I hope you’re taking away methods and ways of thinking about things you hadn’t considered before.
In this case, I applied a tongue-in-cheek work (The Zen) to a set of very real organization issues where now, maybe you can say at the start of the meeting (or the end):
“Explicit is better than implicit, let’s write this down and communicate it widely”
Don’t let things pass silently through tribal knowledge and ambiguity. That’s how you fail. Just remember to not beat people up, you can pass the message on with finesse without being an ass.
