Feigning Surprise

Two months into my first job out of college, I screwed up the source control (where we store all the code) for our team. It was my first time using any sort of source control (those were the days before GitHub and yes, there was such a time!). The whole source repo is locked and none of my teammates could commit code for more than an hour. The tech lead for the team dropped by, sighed, typed up a few commands (svn cleanup <working_copy> being the last) which fixed the issue. He just stared at me like, how could you miss such an obvious thing, and left. Nothing more.

Acting surprised as though the other person doesn’t know some “basic” thing isn’t an uncommon behavior. I always felt this behavior was problematic, but couldn’t clearly articulate or reason through it until I came across these rules from Recurse school. It then hit home for me that this a common enough behavior that a certain institution made it a rule not allowing this. The irony is, I myself am guilty of scenarios where I feigned surprise and got hard feedback about it. Even if it is natural for you to react a certain way, it serves no purpose other than it might make you feel smug. It immediately makes the person who asked the question, doubt their own talent, discourages them from asking questions and makes them hesitant to approach you to ask questions in future.

And there is a whole another level to it, if the person has a background unlike most of the other folks on the team: it seriously affects their confidence. This equally applies when folks from different discipline other than yours are trying to learn about a topic from you. What we consider “basic” is strictly domain dependent and doesn’t take into account myriad of backgrounds of people we work with.

Now consider what happens when instead of making someone feel insecure about what they know we create spaces where it is OK to not know and learning new things and new ways of problem solving is part of your daily experience. We help them find opportunities that stretch the boundaries of their knowledge and skills. And the growth that follows enables not only their careers but makes our team that much more effective.

This reminds me of another story from 15 years ago, I recall as vividly as the first one. During my first internship, I was working on a small toy RPC chat application on the side, which is of no real consequence to the company. My Tech Lead pulled me out of that and assigned me a project alongside another Senior Engineer on the team on one of the most critical launches for the team. The fact she believed in me, when I was not sure of what my value was to the team, is something I still cherish to this day.

That brings me to a great tweet I came across during the weekend:

How we want to be remembered in a decade is a decision we can make every single day when we walk through the door. The choice is ours.