This is the listening series. Check out all the posts in the series here.
Two posts ago, we talked about two skills I have worked on to increase my impact in collaborations: deliberate inquisition and deliberate appreciation. The last post focused on deliberate inquisition, and now we’ve reached deliberate appreciation.
Let’s start with a seemingly unrelated concept: the concept of the 10x developer.
What does it mean to be a 10x developer?
The software community has this idea of a theoretical individual who does ten times as much work as a “normal developer.”
The mind defaults—as does the software community—to the idea of a developer who individually produces ten times as much code as other developers. Shekhar Kirani’s tweet thread about how to spot a 10x developer exemplifies this viewpoint:
These snippets from Kirani’s tweet thread characterize the idea at its most toxic. He got dragged on Twitter for liberally using fake metrics, advocating for behaviors that damage team effectiveness, and requiring skills that people don’t actually have (I write English better than most developers, for example, and I don’t even do that “no breaks, no pause”). The critiques of the thread mirror common critiques of this perspective on the 10x developer as a whole.
Critics of this line of thinking sometimes attempt to salvage the idea of the 10x developer. They say it isn’t about writing code quickly, but rather about asking the right questions so the right thing gets built. This blog post exemplifies that point of view, and there’s a kernel of truth in it. I’ve spent years of my career as a codeslinger (sometimes colloquially referred to as a “slinger”). A slinger rolls onto client projects and writes code at high velocity, usually for a period of months to a year. Typically, a slinger focuses on picking up tickets, while a product manager focuses on what to build.
The skill of the product manager affects the velocity of the team far more than the speed of the slingers. Why? Because if work needs to be undone or redone a different way, a double-speed slinger just got twice as far in the wrong direction by the time the team received the news. So the PM needs to collect information to make (hopefully) accurate decisions about what the software should do. I’ve worked with about two dozen PMs. Two were incredible, another four were good, another six were fine, and the rest—half of the group—regularly had developers undoing and redoing things where the right questions would have prevented it.
So in this respect, asking the right questions does get more work done. If a developer can ask those questions, that’s great. But does it accomplish ten times as much work? No. It accomplishes maybe twice as much work. If especially poor management produced a lot of whiplash, three to four times as much work.
Some people say that the 10x developer is a myth for precisely that reason: there is no way for one person to get ten times as much done as another person.
And I think that’s probably true. But I also think that it’s not a particularly useful way to circumscribe the 10x idea.
If 10x as much work gets done, I’m happy regardless of who did it. And I do think that a developer can enable 10x as much work to get done as a lone individual contributor. They can do that by enabling nine other developers.
Here’s a seemingly unrelated question:
Why do activist movements care so much about phone banking?
Phone banking means taking a big list of phone numbers and calling those numbers to ask people to do things like vote, donate, or attend a protest. It is the highest leverage thing any given individual volunteer can do for an activist organization.1
Why, when we stage protests, do we encourage people to participate in phone banks before we encourage them to attend the protest itself?
Because if a volunteer comes to the protest, they increase our numbers by one. And if they call thirty people, three of whom come to the protest, they increase our numbers by three. A phone banker’s enlistment of attendants impacts the event more than their attendance does.
The amount of impact that you can individually achieve is a drop in the bucket compared to the amount of impact that you can inspire in others.
Having a multiplicative impact requires helping others reach their potential.
Which you (or I) can do by investing time and energy in deliberately appreciating others for their presence and for their work.
How do we do that? There are lots of ways. It’s likely that you have met wonderful, nurturing souls in your life who do these things automatically. But even if we don’t do these things automatically, we can challenge ourselves to wake up each day and try to do at least one. Or, as we get more advanced, we can aim for two, or three, or more, until we have changed our default behavior.
Examples of ways to deliberately appreciate others:
1. Give a genuine, specific compliment on something someone did, what you specifically liked about it, and how it affected you. Bonus: nourish their potential by including encouragement of how they might take this further.
Example: “I really appreciated the picture you drew yesterday to visualize the connections between these two pieces of software. I found that a pictorial explanation worked really well for me in a way that verbal and written explanations have not. Have you considered giving a talk about how to draw software systems like that?”
2. Give someone a thoughtful gift, especially on a day where they are not feeling well.
Example: One time my manager brought me a latte the day after he knew I had received some disappointing news. His thoughtful gesture shifted me, albeit temporarily, from a loss mindset to a gratitude mindset, which positively affected my mood long after I had finished the latte.
This one is kind of a double whammy because he hadn’t just brought me any gift—he had brought me a thing that I’m pretty vocal about enjoying. This showed me that he listens to me (or got lucky, but I’m giving him the benefit of the doubt).
3. Listen to what they say, ask them questions about the projects they are working on, and show interest in what they’re trying to do.
This is what we have been learning to work on in the previous six posts of this series.
4. Look at the projects that they have worked on and tell them what you are learning from them.
Example: A friend of mine and I got into a conversation about their doctoral thesis. They were proud of the research they had done and had reached some conclusions that meant a lot to them. They cared enough about this thesis that they sent me a link to the pdf. So I printed the PDF and marked it up for my comprehension (by the way, this is how I approach academic papers). My friend was dumbfounded when they discovered in a later conversation that I had read the thing. I don’t think they’ll ever forget it.
5. Ask them for advice on something in which they have expertise.
Example: I had a colleague once who asked me how I would approach modeling an object graph model for an app they were starting. I had spent the prior 4 months building a different app on top of a different graph database, and had done a lot of reading and thinking on the topic. Worth noting: the person who asked for my viewpoint had written several graph database schemas before, and also had about five times as many years in coding as I did at the time. So they didn’t strictly need my opinion. For this reason, I’ll never forget the effort they made to solicit what I had to say.
6. Accept their advice or suggestions, and follow up with them to share that you did it.
You don’t have to accept every piece of advice you ever receive. But when you do, you can let people know.
Example: When I accept a friend’s book recommendation, I do my best to let them know when I start the book, and also when I finish it.
7. When people correct you, admit your part where you were wrong and thank them for the correction.
It’s natural to get defensive when we feel attacked. But if we can manage to admit where we were wrong and thank the person who let us know, we signal that their views matter to us.
If you want more on this topic, this is this post for you.
But people are busy, Chelsea. Who has time for me to stop them and do this?
Almost everyone in your life has time for your genuine appreciation.
I don’t mean Beyoncé. I mean people with whom you have mutual relationships and not parasocial ones.
Appreciation suffers from a tragedy of the commons effect that we talked about here, as well as a Kitty Genovese effect with respect to “obviously” high achievers (“they’re so amazing, surely other people are already telling them how amazing they are, they don’t need to hear from me”). More often than not, the person you appreciate would be doing better if you told them so.
Chelsea, how do I show appreciation without being accused of harassment?
I’ve had several men cite a personal principle of not showing appreciation to women because they don’t want those women to think they’re coming onto them.
Here’s a rule of thumb:
- Not sketchy: complimenting someone’s writing, programming, or insight
- Possibly Sketchy: complimenting someone’s appearance, body parts, or smell
If you’re not sure where the line is, stick to their work.
Chelsea, what if I’m constantly expected to do all the appreciating?
I’ll be frank here. I’m a woman. My job is engineer. And yet, in the workplace, I have had bosses attempt to put me in charge of:
- planning team outings and team morale activities
- remembering birthdays and buying birthday cards for the team
- changing the abrupt, culturally incompetent wording in their company missives to more inclusive wording
- providing them therapy in 1-on-1s theoretically supposed to be about my career
There is a systemic pattern, in tech and elsewhere, of placing the burden of emotional labor squarely on the shoulders of women (and more generally, tilting it heavily toward folks from underrepresented groups).
The last thing I want is for somebody to send this post, or any post from the listening series, to someone from a less privileged group as instruction on how to better serve the emotional needs of others.
So here is my challenge to you, dear reader:
Please take this series as a set of tools at your disposal to operationalize your personal goals for building your career skills. I’ll let you decide whether it would be appropriate for you to share the series with people who have more privilege than you do.
Please think very very hard before sending this post, or any part of this series, to someone with less privilege than you; a subordinate, but particularly, a woman, or a black person, or a disabled person, if you are not those things, just as examples. Those folks with less privilege than you have already been asked to do more listening and appreciating in their careers than their positions should have demanded. If they wish to find this series and improve at those skills, that’s grand, but I would prefer that my work not be used to reinforce gendered or otherwise socially stratified expectations about who is expected to deploy these skills on demand.
And here is my challenge to me.
I’d like to close the listening series with a piece of deliberate appreciation for you, dear readers. I hesitated to write this series because of the personal nature of the content and the personal nature of the incident that led me to research it. I cannot tell you all how much your words of encouragement on Slack and Twitter have meant to me as I have written this series.
And if you’d like to see me do more series like this one, you can help make that happen by becoming a patron.
1 Did you know how much activist organizations appreciate phone banking, and why? Did your ears perk up at this potential clue about how to get started in activism? Here’s an easter egg for you: in addition to this blog, I keep a (far less reliably updated) personal blog which contains a piece on getting started in activism, written for the socially anxious and despondent.