February 18, 2020

Maker <-> Puzzler

Every engineer I’ve met falls somewhere on this spectrum:

One side is Maker, the people who like engineering because they like building things. They often get joy and satisfaction from seeing a thing they built out in the world and used by people. Makers tend to flock to product-focused companies.

One side is Puzzler. A Puzzler gets their joy and satisfaction from overcoming difficult problems. They might feel an electric sense when all the pieces come together, and when the universe feels theirs to command. Puzzlers tend to flock to companies with deep pockets of thorny technical problems.

This specturm comes from the answers to this question: “What do you like about engineering?” I’ve asked this question to dozens, maybe hundreds, of engineers, and the answers I’ve received gravitate towards either “I like to make things” or “I like solving puzzles.” That “gravitate” here is an important word, as is the fact that I’m calling this a spectrum, not a binary.

Every engineer I’ve met is closer to one pole than another, but I’ve never met anyone who is entirely one or the other. Beyond that, how much an engineer leans towards Maker or Puzzler can change over the course of their careers, because of the company they’ve joined, or even from project to project.

I know about myself that I lean heavily towards Maker. I get deep satisfaction from building systems that others use. I still get the electric thrill from solving a thorny technical problem, but my deep well of satisfaction comes from having built something and continuing to improve it.

Where you fall on this spectrum says nothing about your quality as an engineer. Excellent engineers come at every spot on the line. What it tells you is where you’re likely to draw the most satisfaction, and how you’re likely to go find new projects. If you know you lean Maker, a project that involves a lot of research and technical spelunking might exhaust you. If you lean Puzzler, a project that provides value to the user by cloning an existing pattern might leave you feeling unsatisfied.

For technical leaders, this is another criteria by which to evaluate your next hire. I strive for balance in my teams, a healthy blend of people who focus on building and getting things done alongside those who delight in technical puzzle deep-dives. I think about this spectrum and my current team make-up when I’m crafting a job posting and developing the interview panel for a role.

Where do you fall on the spectrum? Where do you think your teammates fall? What aspects of the Maker <-> Puzzler spectrum might need balancing on your team?

engineering culture

February 5, 2020

Minimalism’s Natural Habitat

I’ve been thinking about minimalism wrong for a few years now, and it took my first trip to Japan for me to realize it. If you had asked me before my trip, before November of 2019, I would have said that simplicity was the point of minimalism. This sounds like a tautology, because my logic was flawed — I thought simplicity for the sake of simplicity was part of minimalism’s ultimate goal.

There are elements to modern Japanese design that are breath-taking in their simplicity. I’m thinking here of the single perfectly pruned flower in a vase, or the whorls of sand around a stone in a garden, or the striking architecture of a temple gate leading off a city street. I use “breath-taking” because it conjures a feeling of surprise, and that’s part of what I mean. I was surprised by some of the simple beauty that I saw, but the nature of surprise means that what I’m seeing was different than what I expected.

What I came to expect as I wandered Tokyo was not minimalism, but a sensory assault. Tokyo is a city that wants you, the visitor, to buy things, and buy lots of them. Encouraging you to buy requires advertisements. The only ads in Tokyo that are truly minimal are for perfume, and most of those appear to be placed by Western companies. Minimalism is highly present in Tokyo, but in my experience the minimal spaces were the spaces designed as an escape from the life outside. Our hotel room was sparely furnished, and those furnishings were simple. After a day in Tokyo that minimal space, which would have felt like a cloister cell in California, was a welcome relief for our senses. I was surprised by the minimalism in Japan constantly — because it was so different from what my mind became trained to expect.

Minimalism surprises, and minimalism highlights. The element of surprise gets all our senses focused on what the artist is trying to highlight. The simple design of Japanese restaurants focuses attention on the food the chef is preparing. The simple architecture of a home highlights the color and beauty of formal Japanese dress. The crowd and noise and signage of the streets highlights the peace of the temple.

Before Tokyo, I thought about Minimalism wrong because I wasn’t using the simplicity to surprise and highlight. I was advocating for simplicity for the sake of simplicity, with no clear subject to focus on. Minimalism’s natural habitat is in crowd, so that through it’s calmness it can point out what matters most.

minimalism Japan design

February 3, 2020

Tech salaries are risk premiums

This blog post was supposed to come out two years ago in response to, I think, this article. Better late than never?

---

After literally years of people telling me I should read Matt Levine’s Money Stuff, I finally started reading Matt Levine’s Money Stuff. One takeaway from this is that I am susceptible to social pressure if I respect the people applying the pressure highly enough. The more interesting takeaway is the conversation I had with Asheesh Laroia immediately after reading a particular edition of Money Stuff.

Asheesh: “risk premium” is a powerful concept, and I really love that Matt Levine gets that.
Me: All tech salaries are risk premiums in both directions.
Asheesh: o_0 I need like a 3 sentence version of that.

Here’s the much-more-than-3 sentence version that started in my head and ended up as a collaboration between Asheesh and I.

Let’s say you work in tech. The average tech company wants to pay you the minimum they can. This is not unique to tech companies, all companies want to do this, but the example here is tech. They pay you more as a risk premium to keep you from leaving, which can be a substantial risk to the company. You, average tech worker, know in your head the absolute minimum salary you’ll take, but aim far higher than that in job search and negotiation as a partial risk premium against getting fired, going broke, and the cut you’re taking from not working at AppAmaGooFaceSoft.

That “not working at AppAmaGooFaceSoft” is a pretty important bit here. The risk you and your potential employer are guarding against is modulated by your actual ability to work at AppAmaGooFaceSoft, which probably neither you nor the company you’re trying to work for have evaluated well. At the very least, that possibility is opaque to your potential employer. This is the kind of low-knowledge, high-risk situation well-suited to risk premiums.

Here’s where it gets interesting: AppAmaGooFaceSoft could decrease average tech salaries by promising to interview everyone within some timeframe of you applying, effectively calling your bluff to the person across the table from you. If AppAmaGooFaceSoft says they’ll interview everyone who applies and get back to them in a 48 hour window, with a 48 hour exploding offer, then everyone would know if you were bluffing with your pretend invisible AppAmaGooFaceSoft offer for more than a week.

Taking this further, imagine AppAmaGooFaceSoft enacting a hiring freeze from May to September. All of recruiting decides to take the Summer off, and no one gets in the door. During those months, if you’re job shopping, it means you have no credible likelihood that AppAmaGooFaceSoft is someone a company should be competing against, and therefore you have less negotiating power than you do during the months AppAmaGooFaceSoft is hiring.

Let’s keep going! If AppAmaGooFaceSoft ever stops hiring, if one day the heads of recruiting at those companies say “Nope, that’s it, we’re done, full house over here” then the ripples in tech salaries will be felt across the whole industry. Salaries will be driven down, because working at AppAmaGooFaceSoft is no longer a bargaining chip. It might cause a tech salary “crash”, where salaries drop way closer to the skilled worker median.

Of course, this only works if all of AppAmaGooFaceSoft do this simultaneously. If Facebook stops hiring, Google will pick up the slack. If Amazon stops hiring, Microsoft will happily absorb many of those workers.

There’s an interesting corollary for you, the person not applying to AppAmaGooFaceSoft: You want those tech mega corps to succeed, and keep driving salaries up, even if you don’t work for any of them, because they’re helping to lift your salary at Random Startup, Inc.

Here’s where we reach our very strange conclusion. If we take the above as true, then every family member you convince to buy an iPhone or use Gmail or subscribe to Amazon Prime is contributing some small percentage to your salary increases at Random Startup, Inc. Which is a fascinating, if deeply disturbing and perverse, incentive.

startups salaries AppAmaGooFaceSoft

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:

1. Revitalizing a Disney property in a way that feels charming and modern.
2. 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:

1. Generating the best creative content possible.
2. Fostering innovation and utilizing the latest technology.
3. 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.

growth companies Disney

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.

books reviews management

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].

tech management