Rising to the Role

Take away the person you rely on and you’ll become that person.

A child rising to the role of President in the absence of his mother.

When it’s just her and I, my girlfriend can be bratty and indecisive. When I try to get her to do something she doesn’t want to do, like wake up or go to bed early, she whines like a little kid who’s being forced to eat their vegetables. When we’re out for dinner, she can never decide what she wants to eat. She’ll debate between two items for 15 minutes, before finally coming to a decision. But when the waitress finally comes to take her order, she makes me choose for her at the last minute. It’s shocking to imagine that this same woman could act like a mature and decisive dictator. Yet around her younger sister, she does just that.

She talks to her sister in a stern, authoritative tone, especially when commanding her to do chores, listen to her parents, or go to bed. She suddenly becomes Albert Einstein when her sister asks her a question or Sun Tzu when there’s a decision to be made. When she’s the one being relied on and looked to for guidance, she rises to the responsibility. She believes that if her sister was left to her own devices, she’d TikTok the night away without doing any homework or chores. Yet I’m confident that if her younger sister was alone, or had to take care of someone even younger, she would rise to the occasion and instantly become more responsible.

Take away the person you rely on and you’ll become that person. This doesn’t just apply to family and relationships, but also to your career. If you’re on a team with someone that you know can solve a problem, you’re going to go to that person when you can’t solve it yourself. But when there’s no one to go to for help, you somehow manage to figure it out. Just knowing that there’s someone who can solve a problem for you is going to reduce the amount of time and effort you spend on it. We think of our mentors as wise Jedi who’ve channeled the force, but really, they’re just normal people who've spent lots of time and effort solving similar problems in the past.

Mentorship is great for optimizing the learning process and accelerating the acquisition of knowledge. You get to hear war stories and distill learnings from your mentor without having to spend the time and effort required to actually experience the metaphorical war that led to those learnings. But for maximal growth, you need to balance the receipt of mentorship with solo struggle. There’s no substitute for facing a problem while knowing that no one is going to save you from it. If you spend too much time under the thumb of your mentor, you can develop an unhealthy reliance on them and become lazy.

Early on in my career, I had an incredibly knowledgeable mentor named Morgan. From day one, Morgan was eager to help and answered all of my questions with the precision of a surgeon and the depth of the Grand Canyon. His answers were great, and to my naïve intern self, he seemed to have them for everything. If I couldn’t figure something out in 20-30 minutes, I’d shoot Morgan a message and ask for help. What I wasn’t aware of, was that Morgan didn’t know the answers to all the questions I asked him either. In fact, he probably didn’t know the answers to most of my inquiries. But what he did know, was how to find them.

He’d search up the question in the modern library of Alexandria (Google), parse through the results for relevant answers, and then test those answers against the question to make sure they were correct. He’d think deeply about what was asked. When it had to do with a piece of code not working or an error being thrown (we worked as software developers), he would actually read the error message and try to understand the series of events that led to the problem. Once he figured it out, he would synthesize his answer into a descriptive text message, and send it to me. Morgan was becoming a master of answering questions. And I was becoming a master of asking Morgan questions.

The more questions he answered, the less time I would wait before asking for help. My 20 minutes of self-investigation shrank to 10 minutes then to 5. And unfortunately for both Morgan and I, he continued to help. I wasn’t developing my own problem-solving or knowledge acquisition skills and he didn’t have much time to do his own work. Something had to change.

Luckily, on one of Morgan’s days off, I came to the uncomfortable realization that I was greatly overutilizing his problem-solving prowess. While coding up a new feature, I encountered an error that was preventing the program from starting. I copy-pasted the error message and immediately began to send a DM to Morgan asking for help. To my dismay, the status indicator next to his avatar was grey. He was offline. I suppressed my initial panic, took a deep breath, and tried to figure out the problem on my own. I started by actually reading the error message. There were some familiar words, and the stack trace referenced lines of code I had written earlier that day. As I read and re-read the stack trace a dozen times, I was able to isolate the root cause of the bug. I started Googling and found an answer on StackOverflow that was very similar to the problem I was dealing with. I tried the solution proposed in the first, most up-voted answer. It didn’t work. I then tried the second most popular answer. Still didn’t work. Then I tried the third answer and… VOILA! The program burst to life and the error message was gone. But I didn’t stop there. I wanted to know why this answer worked. I purposefully reintroduced the bug to the program and tried to make it go away on my own. I read and re-read the answer a dozen times until I understood why it solved the issue I was having. Finally, I was able to squash my purposefully-introduced bug without referencing StackOverflow. I understood why the program wasn’t working, how to fix it, and why the fix worked. That day I learned to diagnose and solve a complex bug on my own, and it felt good. Addicting almost.

When there was no one to go to for help, I had no choice but to help myself. I had no self-imposed time limit after which I would reach out for help. I was the help. Necessity bred the resourcefulness I needed to figure it out. The next time I went to message Morgan for help, I consciously stopped myself and asked, “Have I put in my best effort to find the solution to this problem?” The answer was of course, “no.” I deleted my draft message and spent the next hour figuring it out by myself. I continued this pattern, consciously resisting the urge to seek Morgan’s help unless I was completely lost. Slowly but surely, my ability to find my own solutions flourished. Sure, I would still occasionally need to reach out for help; I was an intern with less than 3 months of experience, but this time my requests for help wouldn’t come until I’d exhausted all the avenues I knew of.

When we’re confronted with a problem and there’s no one there to help us, we figure it out. It takes time. It’s hard. But we get it done. It seems that just knowing that we’re on our own, with no one to help us, raises our ability beyond what we thought was possible. If we were in the same scenario but with someone we knew could solve the problem for us, we’d quit prematurely and get them to help. If you want to improve at something, embrace this phenomenon and put yourself in an environment where there’s no one to go to for help or where you’re the one being relied on. I’m convinced that if you put four equally skilled and knowledgeable engineers on a team, label one of them “principal engineer” and designate them as the leader of the group while labelling the others “intermediate engineer”, the “principal engineer” would rise to the role and develop much faster than the others. The “principal engineer” would rapidly gain knowledge and experience from answering questions posed by the “intermediate engineers”, all of whom are just as capable of answering the questions on their own.