This is the listening series. Last time, we left off on this question:
From how many discussions have I hewn away value by opening my mouth ahead of someone with something more valuable to say?
This question has completely changed my perspective on my goals in a discussion and how to reach them.
For in-person discussions, I have consciously shifted my focus. Instead of optimizing for my own airtime, I optimize for my two other things: my learning and my impact. In this post, we’ll talk about learning. In a future post, we’ll talk about impact.
I focus on how each discussion can broaden my skill set and perspective. In fact, I am more concerned about learning than about looking like I contributed.
It sounds noble and altruistic, but the motivation here can be selfish. We talked in the past about the career impact of learning versus looking good. The important part:
As a technical contributor, you are probably not going to get promoted.
It’s sort of a joke in the industry that if you want to move up, your best bet is to switch companies. There’s a reason for this: when someone is already delivering superior output, there’s no benefit to the company to pay them more for the output they already deliver. So managers will neg these people or string them along without a real promo in sight.
Compare this to if the company is hiring for a position at a higher level: it’s hard to find technologists in the first place, and that disparity grows as you go up in level. So if the company can get just one candidate in the door for a high-experience technical contributor position, their incentive is to find that person capable of the position because they might not get another candidate.
So what does it take [to get promoted]? In my experience, it takes convincing a manager or director with more power than you to compile a case for you like they’re your attorney.
[So] persuading, cajoling, and convincing managers has more of an impact on your advancement than your technical contributions do, because if you just kick ass at your job, they are either not informed or not motivated to go to bat for you. But spending the time to persuade, cajole, and convince managers means spending time that you might otherwise spend kicking ass at your job, or leveling up so you can kick more ass at your job.
So if that’s the case, who cares if you need a little help sometimes? Get the help, let people think you’re a hack, increase your actual skill level, and let it help you land that promotion at another company when you’re ready. Your next employer isn’t (usually) going to call your current boss and ask their opinion of your skills.
I see a higher return on investment from advancing my skill set at work than showing it off there. People I’d want to work with again will see it anyway.
There’s a relationship between learning and talking. This quote sums up that relationship quite well:1
Often—far more often than I used to estimate—I do more good for myself and for others by keeping my mouth shut. So, nowadays, I don’t pipe up whenever I happen to feel like talking.
So what am I doing instead? And when do I talk?
What am I doing instead of talking?
I am soaking up information from the other people who are talking.
Every discussion involves at least two people with different experiences. The more I can learn about my conversation partner’s experiences, the more I get to know about without having to win all those lessons myself.
So in a conversation, I want to determine what experiences my conversation partner has had that might be complementary to mine:
- What sorts of work have they done? Am I interested in things that they have done that I haven’t done? Can I ask them about those things later?
- Have they tackled similar problems to me? What were their takeaways from those experiences? Are they the same as mine, or different? Why?
- What are their individual values and goals? Can I do anything to help them reach those goals? Do I want to?
I can scarcely believe my luck at the opportunities I unearth by listening closely to others. For example, these days I have turned my focus to learning about interpreters with the eventual hope of building languages and tools for scientists and engineers. Somehow, everywhere I go, someone teaches me something that helps me with this goal. The phenomenon makes me wonder how many opportunities I have missed in the past by focusing on my own comments over what others have to say.
Here’s another example: hiring. Because I have technical privilege and visibility in the tech community, people often reach out to see if I want a job. I’m pretty explicit about what I’m looking for, so it’s often not a fit. But I can frequently connect the company to a colleague for whom this is the dream job that they thought they wouldn’t find. How do I know? Because I listen to my colleagues and I understand their goals.
It doesn’t even have to be professional stuff. I have learned this year about hardships my colleagues have been through, triumphs they have accomplished, and lessons they have learned about themselves, about relationships, about priorities.
We all have to deal with hard things. You know what makes it even harder? Feeling alone in the process.
By listening to others, I have learned that many of my personal conflicts, insecurities, and dilemmas are far more common than I think they are. I have become able to give my colleagues a priceless gift: I have learned to be present with them when they need someone. I have also had colleagues give me that gift. And it has made the hard things in life a little bit easier.
But that requires vulnerability. It requires bringing our whole selves to work—anger, sadness, loneliness, all of it. I’s hard, and sometimes unsafe, for us to share our whole selves in a context where people might not be fully listening to us. Listening makes it possible for work (or anywhere) to become an energizing, healing place, rather than a draining one.
All that magic can happen in a conversation with just one person.
There’s even more to learn in the context of a meeting with multiple people. Meetings have complicated dynamics that help me understand what I can do to help. So I observe the meeting to learn about these dynamics:
- What are we trying to decide in this meeting?
- Which options have support, and which do not? Why?
- Who is everybody trying to convince? Is that person in this meeting?
- What else are people in the room trying to get?
The answers to these questions can adjust my perspective on what I might even want to say in this meeting. So by listening first, I avoid barging into a conversation with a perspective I might regret sharing later.
That dovetails nicely with our next question.
If I don’t just speak up whenever, then when do I talk?
I rarely share my opinions until someone asks me a question.2
By doing that, I get to delay my decisions until the last responsible moment. We talk about the “last responsible moment” in agile software development. At the beginning of a project, we have the least information with which to make decisions. So to avoid wasted effort, we delay decisions for as long as possible to collect information that will inform those decisions.
In that spirit, I collect information before speaking up. And then, even when someone asks me to share my thoughts, I tend to ask questions. Those questions help me learn even more. (We’ll talk more about questions later).
This has a convenient side-effect: I can avoid questions I don’t want to answer without drawing attention to the fact that I’m avoiding them. It turns out that, even if people have asked me what I have to say, they rarely notice if I never answer.
That sounds inaccurate, doesn’t it?
Let’s more about that in the next post.
1 Not an endorsement of all of the Dalai Lama’s views. This is a tech blog, so I’ll let you do your own research here.
2 I’m saying that I rarely talk unless asked, but there are a few exceptions. We talk about exceptions in normal discussions in the next post. In addition to those, there is a special case discussion: an assisted processing conversation. When I am processing something that makes me sad or angry, I’ll sometimes ask for help from someone else. That’s a specific kind of conversation that includes room for me to rant and carry on while the other person listens. I set that expectation at the beginning of the conversation, ask the person’s permission before launching into it, and choose a conversation partner who can say no to me without fear of consequence. This post goes into more detail on assisted processing.
If you liked this piece, you might also like:
The remote work series (a favorite among colleagues who also like the listening series)
Build Graceful Processes (Idk, maybe of interest to engineers who care about listening)
The Case for Pair Programming (complete with cute character doodles!)