February 1, 2020
Never just one thing
I think there’s a secret to the most recent run of Mickey Mouse. The most recent Mickey Mouse television series, which ended a multi-decade era where new Mickey content was absent from American television, began airing in 2013. Each season is a set of one-off shorts starring Mickey, Minnie, Goofy, and Donald, with occasional cameos from Pluto, Pete, Daisy, Chip, and Dale. If these names are unfamiliar to you, you are definitely forgiven. Up until this most recent run of Micky Mouse, these characters had faded from the Disney Pantheon and mostly appeared in the parks. They have been given new life by this series.
This series is remarkable. Not only is it re-invigorating these characters in pop culture — with a new art style and all the copyright benefits that entails — but every season features multiple episdoes that are utterly targeted at a non-American audience. Episode 3 of the first season, Croissant de Triomphe, is set in Paris and performed entirely in French. The new run of Mickey Mouse has taken its cast to France, Tokyo, Beijing, Venice, Brazil, Mumbai, the Netherlands, Pamplona, London, Mexico, Russia, Turkey, Hawaii, Egypt, Seoul, Rio de Janeiro, the Serengeti, and Thailand. In most of these episodes, the cast is performing in the native language of the setting. The episode in Thailand, Our Floating Dreams, became such a phenonenon that clips from it started being used for political memes in Thailand.
This series is doing at least two things with every season:
- Revitalizing a Disney property in a way that feels charming and modern.
- Authentically connecting Mickey Mouse to an international audience.
I’ve thought a lot about not doing anything for one reason as I’ve been growing as a leader, first at Patreon, then with Galaxy Brain, and now with Trim. “Never just one thing” is one of the unofficial mottoes of Galaxy Brain, so much so that my co-founder Liam and I say it to each other often. What’s interesting to me is that I had been thinking about this motto as something you only need to do when you’re starting out or scaling up. In my mind, I implicitly thought that if you reached a certain scale your organization had more slack and didn’t have to be as focused on optimization.
I thought that until I watched the documentary series The Imagineering Story, and started watching the new Mickey Mouse. The Imagineering Story chronicles the rise and fall and rise of Disney Imagineering, the workshop behind the Disney Parks internationally. There was a real concern that at the end of Michael Eisner’s reign as CEO of The Walt Disney Company that Disney Imagineering would be shut down completely. What they couldn’t know was that Bob Iger would have three foci when he came on as CEO, three foci of which Disney Imagineering and Disney Animation Studios would play a major part:
- Generating the best creative content possible.
- Fostering innovation and utilizing the latest technology.
- Expanding into new markets around the world.
The Walt Disney Company is massive, and one of the oldest contiguous companies on Earth. To hear the CEO of that company call out a multiple-focus approach, and then to see it in action with the new Mickey Mouse series, drove home something that I now think is true of all successful organizations of any scale:
Never do anything for just one reason.
Never just one thing.
As a post-script, this isn’t a new idea, and is in many ways a return to what Walt originally designed for the Walt Disney Company. To my mind, this is more evidence that the idea was always solid, and that large organizations forget it at their peril.
January 10, 2019
Touring the Breakfast Factory: Thoughts on High Output Management
As I mentioned in my last post, I recently moved from being a Senior Software Engineer to a Team Lead. I’m fortunate to have received the advice early in my career that moving to management is less a promotion and more starting a new job; I immediately started looking for information on how to get better at this new job, fast.
I am doubly fortunate to know Jacob Kaplan-Moss, and to have come across his reading list for new engineering managers last year. As soon as I knew that I was heading towards a management path, I bought every book on his list, including Andrew S. Grove’s High Output Management.
One of my winter break goals was to get through as many books as possible, and High Output Management was at the top of the stack. As soon as I started reading it, I understood why it’s so highly recommended in management circles: it’s the best book on managing teams of people that I’ve read so far. It’s so good, in fact, that some of the best ideas in it seemed obvious to me.The ideas seem obvious because every company I’ve worked for has implemented some part of Grove’s ideas about management. They seem obvious because I have the advantage of living in a world that has had High Output Management in it for the past 30 years.
Take the idea of metrics and outcomes guiding a team. Every company I’ve worked for, especially in tech, has every team or department within it tracking metrics that get reported up the chain on a regular basis. As an engineer, this obsession with team metrics and trying to improve them can seem like a waste of time. “We feel good about the things we’re working on, why do we have to spend so much time quantifying them?”
The answer to this comes almost immediately in High Output Management: Every team is a black box to everyone not on the team, and the only way to know if a team is successful or not is to check the team’s metrics or see what they’ve shipped (which is itself another kind of metric). Thinking about metrics and outcomes in this way permanently changed my approach to teams. I started immediately looking at my team’s reporting metrics not as some arbitrary goal to hit, but as the only measure of the team’s health that most of the rest of the company would see.
Once you start thinking about metrics and outcomes in this way, if you’re like me you’re driven to make sure the metrics are real for your team. “Real” here means that the metrics actually line up with what the team AND the company care about, that your team can do something to affect the metrics, and that the members of the team are bought in to what the metrics represent. That last bit is especially crucial. Once your team knows why the metrics are important and agrees on what they should be, they can start making suggestions for how to improve them that might be better than the planned workstreams.
Speaking of outcomes and ideas that were popularized by High Output Management, let’s talk about OKRs. OKRs are an instance of the endless acronym parade that permeates Silicon Valley, and this one stands for “Objectives and Key Results”. Grove introduces this in talking about “management by objectives” (MBO, hooray another acronym), which is how every team I think I’ve ever been on has been managed without my ever knowing the term. “Objectives and Key Results” is an unfortunately jargon-heavy way to express an idea that I actually love, namely “Here’s where we think we’re going, and here’s how we’ll know if we’re going in the right direction.”
A trivial example. Say I want to get from my house in Alameda to my favorite taco place in Oakland, Xolo. “Get to Xolo” is my objective. There’s a myriad of ways I could check how close I am, and each one of those is a potential key result. I could carefully measure the odometer (metrics based), or I could know that I’m about a quarter of the way there when I hit the dog park, halfway there when I hit the tunnel, and roughly three-quarters of the way there when I turn on 12th st (milestone based). Take this simple idea and expand it to what your team or company cares about, and hopefully some of the chaos of running a team doesn’t just get a little bit clearer.
“Making things clearer over time” could be a subtitle for the book, in fact. Grove lays out his material in such a way that every chapter has at least one idea I found immediately useful, although the later chapters on performance evaluation and especially hiring feel a touch outdated. This is the disadvantage of reading such a seminal book 30 years after it’s publication — Grove’s ideas were so good we adopted many of them and kept iterating!
After reading High Output Management, I’m doubly indebted to Jacob KM and the others who recommended it to me. Once, because it gave me more tools in my management toolbox. Twice, because I know have an iron-clad recommendation for anyone who asks “what books should I read about being a manager?”. Grove’s book is near the top of that list.
Have you read High Output Management? Think I’m wrong in some of my thinking on it, or want to talk about strategies from the book that worked for you? Drop a note in the comments.
January 1, 2019
Senior Engineer -> Team Lead
In November, I was promoted from Senior Software Engineer to Team Lead. As of right now, I lead the Platform team at Patreon, and have three software engineers who report to me. I want to talk about how I realized this was something I wanted, how I made this happen for me, and why I’m excited about it.
First, how did I think this was something I wanted? It’s helpful to know that I am mercilessly driven by the idea of impact. At least once a week, and sometimes multiple times a day, I ask myself these questions: “Am I working on the highest-impact thing I could be working on? If not, why not?” Being impact-driven (which dovetails nicely with being outcomes-driven for devotees of that brand of organizational thinking) means that I’m always looking to increase my impact, and especially looking for tools that will give me more leverage.
For the kind of impact I want to have, the impact to shape customers’ experiences and shape the paths of teams and shape the careers of individuals, the tools available to managers and team leaders are more impactful than the tools available to engineers. Now, I expect some disagreement to that statement, and I welcome discussion in the comments. For the goals I care about, the tools of a manager are higher impact than the tools of an engineer.
How did I make this happen for me? I saw an opportunity, and I pushed for it. That sentence masks a truly monumental amount of privilege, and luck, institutional biases that I think about a lot. Would a non-white, non-dude have been as successful in their push? What institutional biases might have kept those around me from pushing? So, there’s a lot hidden that I would love to go into in another post when I say: “I saw an opportunity, and I pushed for it.”
What opportunity? Well, Patreon is constantly working on becoming a more lean, more agile shop. As a result, in the Summer of this year an Engineering Director was leading the Platform team, at a critical time in the Platform team’s history. We were in the middle of trying to launch the Reddit integration, our Product Manager was on his way out to work full-time on being an author, and we had just hired a new grad engineer. I saw that there was an opportunity for a strong leader to step forward, so I did. What followed was a month and a half of me talking to peers, managers, directors, VPs, and HR folk, to see how feasible this was. I ended up writing my own job description for role that I now occupy, and then vetting that job description in another round with the people I listed above. I began pushing in late September, and in early November my transition to Team Lead become official.
As an aside, why “Team Lead” and not “Engineering Manager”? For one, I’m still doing some engineering work, on the order of 40% of my time. This doesn’t mean “I’m coding 40% of my time” but it does mean I’m doing “Senior Engineer” things with 40% of my time, and “Team Lead” things with the other 60%. I’m also Team Lead for the team I was a Senior Software Engineer on, the Platform team at Patreon, and as a result my number of direct reports is fairly small compared to other Engineering Managers at Patreon.
This is probably obvious since I said above that I wrote the job description, but I am the first and so far only Team Lead at Patreon. There are others who I think would be great at the role, and this is one of the reasons I’m excited about it: Team Lead hopefully gives engineers a chance to explore management without “closing the door” on returning to engineering.
Why am I so excited? At the root is how much I am excited about Patreon, and especially my team at Patreon, and what I think the Platform team is capable of. I’d also be lying by omission if I didn’t mention a few other things: I’m excited by the challenges that management presents, and how different they are from engineering. I’m excited to learn about a whole new discipline of work that has so much impact on engineering, but is not strictly engineering. I’m excited to gain a new lens through which to see the world.
I also really hope I don’t fuck it up. I want to do right by myself, my reports, and the company, in roughly that order. If I’m not doing right by me, I can’t be an effective leader or example. If I’m not doing right by my reports, then my team as a whole suffers, and my measured output as a manager crumbles. If my team is unhappy or unproductive, then the company will as a whole will suffer. The challenge of having to manage the stack of responsibilities, of having to coordinate conflicting demands, of figuring out how to build a team while meeting the needs of each person on the team is a challenge that I’m exceptionally excited about.
Want to know more? Want to challenge me on my thinking or ask questions about how I got here? Leave a comment below or ping me on mastodon at @[email protected].
August 25, 2018
Documentation for Life
As I started writing this post, I got blocked by the dang title. I couldn’t think up one, and so I started writing in the hope that one would come to me.
It’e been a long time since anything was published to this blog. It’s not that I haven’t been writing; if anything my volume of prose has gone up dramatically in the past year as I’ve started pushing for more and more documentation on the teams I work in and the projects I lead.
I think there’s three reasons nothing has been published here in the past year.
For starters, there’s an infinite bikeshed of possibility in running your own blog, powered by software you maintain. See something you want to fix? The bottomless rabbit hole is there, ready and waiting for you to fix it. It becomes nearly impossibly hard to resist the siren song of everything you want to do in code to make the blog better, forgetting of course that the point of the blog is the content, not the chrome.
Secondly, Dunning-Kruger. I’m past the hump of thinking I know anything at all about the subjects I want to talk about, but don’t have the confidence to believe that my observations are valid. This position is, thankfully, changing: I’m starting to get some validation through my work at Patreon and with technical organizations that my experience and opinions are valuable, and worth adding to the collective conversation.
Thirdly, and perhaps most importantly, today especially, is that my my own brain chemistry is acting against my best interests at the moment. There is quite a lot from the last six years of my life that I’m processing, and trying to heal, and covering on a regular basis in therapy. I am out of “fighting for survival” mode, and my brain is taking the break in constant survival stress to raise issues that I need to deal with, and which come with their own flavors of toxic brain chemistry.
So, what do? As I was writing this, and talked above about the fact that my prose output has actually increased, I had the realization that I value documentation to an obsessive degree, and that taking the posts in this blog as attempts at “documenting my life, and the experiences I have in it” might get me around some of those blocks posted above.
We’ll see how it goes, wish me luck.
October 22, 2017
A Brief Guide to Locking Down Your Mastdon Account
Mastodon is currently my favorite social network. I love it so much, I started my own server with some friends, and I’m proud to say it’s still going strong. You can read about The Wandering Shop in my previous post about why I started it.
Part of the reason I love Mastodon and The Wandering Shop is that it’s a social community where we get to define the rules, and we get to control who is and isn’t allowed in our neighborhood. Myself and the other shopkeeper, Annalee, do a good job keeping out the riff-raff as per our Code of Conduct. That said, if you aren’t on our server, or if you want a tighter grip over who you share with, Mastodon provides some of the most comprehensive options I’ve seen for privacy in a social network.
So here are 6 things you can do to lock down your Mastodon account.
1. Develop a good relationship with your server admins
While Mastodon provides some excellent options for blocking people and servers just for your account, involving your server admins will help keep bad actors and bad instances off everyone’s feed, and help the neighborhood feel better as a whole. This is tougher on a large server like mastodon.social, but the admins there still try to respond to reports as they can. That “personal relationship” is one reason why I prefer the smaller servers.
2. Lock your account
The next steps in this guide are going to be found in your Mastodon preferences, which you can find under the “Gear” tab in the Mastodon web interface. This guide, and all the screenshots, assume your server is on Mastodon 2.0, which many servers have moved to by this point.
In Mastodon, locking your account means that you must manually approve every follower. The Mastodon default is anyone can follow anyone else, without approval. Setting this setting will require action from you every time someone wants to follow you, but it also means no-one can follow you without your permission. This is especially important if you want to…
3-4. Set privacy defaults on toots and unlist from search results
The default for toots that you post in Mastodon is “Public”, meaning everyone can see them and re-toot them. The next level of privacy is “Unlisted”, meaning anyone can see them if they go looking for them, or if they follow you, but they won’t show up on the public timelines, like the “Local” feed or the “Federated” feed. The final level of non-direct-message privacy is “Followers-only”. When a toot is followers-only, only your followers can see it, they CANNOT re-toot it, and it won’t show up in any public feeds.
All of these options are available on a per-toot basis in every client I’ve seen, but if you’d like your toots to be more restricted by default, you can change that here. However you are most comfortable using Mastodon is the right way to use Mastodon, but it’s worth noting that interesting toots in the public timelines is how people find other interesting people on Mastodon, and removing your toots from that by default may limit how many people get to appreciate what you have to offer.
On this same preference page is “Opt out of search engine indexing” option, which will translate to your public profile and status pages not being crawled by search engines that respect things like robots.txt files.
5. Set up 2FA for your account
This falls under “Good internet hygiene”, but it’s a good idea to set up two-factor authentication for your account, and Mastodon has made it easy to do so. Accounts getting hacked sucks, turning on 2FA makes that less likely.
6. Donate to Mastodon development and encourage more privacy features
Mastodon is created and run by volunteers, and you can help support the lead developer through the Mastodon Patreon Page. Additionally, suggestions for more privacy features come up all the time in the Mastodon Github, and you can help make them a reality by pitching in your time and expertise.
June 17, 2017
Finding Your Tribe or: Why You Should Join Me at DjangoCon
“If you’re a programmer you should attend technical conferences to further your career.” Some variation of this was said to me so often when I was starting out as a writer of software that it became something like gospel. It became how I approached conferences; I was there to gain skills or a network that would help me further my career in some way, or further the interests of whoever my employer happened to be at the time.
If you approach conferences with this mindset, I think you will be disappointed. I certainly was. And it took a couple years of going to conferences before I realized (with the help of my wife and some close friends, I should point out) that I had the most fun when I focused less on how any particular conference was going to further my career and focused more on making genuine connections with people, and focusing on topics I actually found exciting.
This makes sense to me when I step back to think about it. Writing software, even when you’re on a large project or part of a large team, can be a very lonely, isolating business. We spend most of our time in our own heads, building castles of imagination that we make real through code. Given the viral strains of imposter syndrome, burnout, and depression that runs through our industry, it can feel incredibly difficult to reach out and make connections, to share our problems and commiserate even with our closest peers.
This is the strength of the best conferences for me. Yes, you will learn things at a good technical conference. You will be exposed to ideas and approaches to problems (both technical and social) that you maybe hadn’t thought of before. Delighting in learning is a totally valid reason to attend technical conferences, and part of why I attend so many.
But the primary reason for me is finding and reconnecting with my tribe. Technical conferences, especially in the Python community, are filled with some of the best and brightest people I’ve had the fortune of knowing, and, more than that, are filled with people who are kind, and willing to listen, and also want to connect with others in their community. I will tell you a secret: Many of the best and brightest, those you might be coming to a conference specifically to see speak, are coming because they also want to make those connections. They also want to reach out, commiserate, and find their tribe.
Now let’s talk about DjangoCon, specifically DjangoCon US which is coming up in August. PyCon is the big conference in our community, and it draws the biggest crowds. PyCon is excellent, and I enjoy going every year. I connect with people at PyCon that I basically don’t see for the rest of the year. But where PyCon is the big yearly reunion with the whole community, and can therefore be overwhelming, DjangoCon is the smaller gathering with friends. Where PyCon is, in many ways, a week-long festival for the Python community, DjangoCon is closer to an intimate dinner party, where you can hear more of each other’s conversations, and join in some incredible discussions.
If you’re still searching for a tribe, or want to reconnect with the Python and Django Community, and want to do so in an intimate gathering of friends, I hope you’ll consider attending DjangoCon this year. As an added bonus, you’ll get to hear myself and the other speakers give a frankly incredible lineup of talks. Seriously, I get excited just looking at it.
Now, some people might be turned off by the fact that the conference is in Spokane. It’s a little out of the way, this is true, but this is one of the reasons I get excited about conferences: Chances to visit places I wouldn’t visit otherwise. I’ll also say that the best breakfast I ever had was in a small town in Washington, and I’m excited for the brunch game in Spokane.
If you’re still not sure that DjangoCon is where you’ll find your tribe, I direct you to the opening talk: “The Shy Person’s Guide to Tech Conferences”. DjangoCon is here for you, and we can’t wait to meet you.
Hope to see you in Spokane.
P.S. About that “technical conferences will further your career” thing. Nothing has done more for my career, and my well-being as human, as having a collection of real friends that I’ve met at conferences.