Working with people who are smart(er than you)
Working at Remesh, I have the pleasure of working with some really smart, nice, great people. I consider myself one of these smart, nice, people. I don’t know if I’d go as far as great, but I do consider myself a decent person. In what follows I’m going to set aside the “nice” and the “great” parts and focus on the “smart” part. This isn’t to say that I don’t care about people being nice and great (sub in your own definition of great here) or that it doesn’t matter. I do care, and it does matter. Not only do I find working with nice people to be more enjoyable, I also believe that, in most cases, it enables greater productivity.
I focus on “smart” here because there’s a few things about working with smart people that I have learned that I’d like to share. In particular, I focus on instances where I’ve disagreed with someone smarter than me. I start by sketching out some thoughts on what it means to be smart and smarter. Then I put forward a general pattern of such disagreements. Lastly, I walk through three ideas that I have found helpful in managing, understanding and working through such situations.
Let me start by putting forward a rough idea of what I have in mind by “smart” and “smarter.” To be clear, I do not intend to give an all-encompassing definition or put forward some definitive view of what it means to be smart. Instead, I aim to give enough to detail to make sense of the pattern that follows and the ideas I present alongside it. As such, for my purposes someone who is “smart” is someone who both:
- Knows quite a bit, especially about some particular area like software engineering, Python, or machine learning
- Learns and understands new information rapidly, again especially in a particular area like machine learning etc.
On this account someone is smarter than someone in general, or on a particular topic X, if they know more about X and they are able to learn about X more rapidly than someone else. Of course there could, and likely are, many cases where person p1 meets (a) for a subject like Python and person p2 meets (b) for Python. This would be to say that p1 knows more about Python than p2, but p2 learns new things about Python faster than p1. In such cases we can say that each individual is smarter in a particular way.
There are two final things worth noting about the definition of smart just put forward. First, we often come to know that someone is smarter than us, or someone else, by noticing that they are right about something more often or more frequently. I come to believe that Bill is really smart when it comes to Python because he almost always knows the answer to my questions (what he tells me works, it solves my problem) or, if he doesn’t know the answer, he is able to quickly figure it out. Second, just because Bill is smarter it doesn’t guarantee that he will get the right answer. With all of this in mind I now turn to a generalized pattern of disagreement that I’ve experienced when working with people who are smarter than me.
The generalized pattern looks like this:
Team is presented with a problem P: We need to build a feature that does X or We need to make X faster etc. (The problem scope can be specific, like “allow users to approve new job requests” or general “build a system that does X”)
Smarter than me Bill: We should take Approach A
Me, after some thought: We should take Approach B (where B is mutually exclusive from A)
I now need, or at least want, to determine which, if either of us, is right. Sometimes it is enough to appeal to the broader team. At Remesh I’ve been blessed to work on teams with multiple smart people, sometimes many or all of whom are smarter than me. If Also Smarter than me Alan says we should take Approach A and the decision is small enough I just get onboard and move on. However, I’ve experienced many a time where either one of the following is true: (a) only Bill and I are deep enough into the problem (or have the required background knowledge etc.) to have a real take on the various approaches, or (b) the broader team is mixed when it comes to the two approaches or lacks strong opinions/points of view. So what do I do in these situations and what have I learned from them?
The first thing I try to do in these cases of disagreement is figure out if I’m “ahead” or “behind.” Am I the smarter individual who has more knowledge in this domain and more context with respect to problem P, i.e., am I “ahead”? Or, is Bill smarter and the one with more knowledge and context, i.e., am I “behind”? It isn’t always easy or possible to figure out whether you are ahead or behind, but the upshot of doing so is that you get a sense of who is missing information and who is at least more likely to be right (and in turn which approach). If I am ahead, then I would start by focusing on why my Approach B is superior and attempt to figure out what knowledge or information I could share with Bill to get him to see this. If I am behind, I would start by focusing on Approach A and trying to figure out what additional knowledge or information would bring me around to agreeing it is the superior approach.To be sure, the “ahead” or “behind” axis is just one avenue for making progress and it does not exhaust all of the possibilities (it could turn out that through knowledge sharing Bill and I actually settle on a new Approach C). However, it is an that I have found to be effective in many cases and, accordingly, a good place to start.
The next thing I try to do in these cases is figure out what more specific ideas, thoughts, or propositions are being disagreed about. Obviously Bill and I disagree about whether we should take Approach A, but why exactly do we disagree? Do we have a different set of requirements in mind? Do we disagree about how much time we have to solve the problem or the availability and talents of the individuals who will be solving the problem with us? (As an aside, I have frequently seen individuals smarter than me make the mistake of assuming that others who will help solve the problem are as talented, productive etc. as they are.) Do we have a different understanding about how some language, system, framework, or existing code works? In most, if not all, of these cases, if we can determine what it is that we disagree about we can simply figure out what the right answer is by looking things up, trying things out, or asking others. We can figure out if a framework provides a particular feature. We can go back to stakeholders and ask them whether or not a specific requirement actually holds.
The last thing that I try to do in these situations is to embrace either being right or wrong and to do it as quickly as possible. For most people being right is easy, however, when you know that Bill is smarter than you it can be more difficult because, by default, you are used to accepting what Bill says on particular topics and you know that historically he is often right. Thus, when working with smarter people I try to quickly figure out if there’s a possibility that I am ahead because I have additional context and, if so, I try to share that information as clearly as possible. At this point in my life I’ve eaten enough humble pie to easily embrace being wrong, but this too can be challenging. It requires you to get over yourself and accept that you make mistakes. It also requires you to learn or understand what it is that Smarter than you Bill knows that you do not.
In summary, I have put forward some thoughts about working with people who are smarter than me. I began by giving a rough idea of what I have in mind by “smarter than,” which mostly boils down to knowing more about a particular area as indicated by being right more often in said area. I then outlined a general pattern of disagreement I sometimes encounter when working with smart people and some concrete ideas towards quickly and effectively resolving the disagreement. In particular, I suggested the heuristic of “ahead” or “behind” to figure out which approach is worth looking at first. While I do not think this can be used to resolve or explain all disagreements, I do think it is effective in many cases, especially when time is of the essence. Here resolving production issues in real-time comes to mind. Feel free to share some of your own experiences and approaches in the comments.
