The Discomfort Is The Point: Learning is both part of the job and the result of doing the job

There is an uncomfortable feeling that comes with walking into a room where you are supposed to be the one with answers, and knowing deep down that you are just figuring it out in real time. I have had to live in that discomfort for the better part of the last 8 months, and somewhere in the midst of all the chaos, I’ve found what might be the most useful lesson in my career.

My name is Elvis, and I have been developing software for the last four years. It is where I have built my professional habits. I know what it feels like to be genuinely good at something, to move through a problem with the kind of ease that only comes from repetition and deep familiarity and working to meet my own deadlines. Then I stepped into a project manager role in a startup environment, and that ease evaporated. Each task depended on another task, each one with its own deadline. If one slipped, three more slipped with it. This meant I had to know who was blocked, what depended on what, which deadlines were realistic, and where the next bottleneck was likely to appear. It was much easier when I only had to worry about my Trello card.

One thing about PM roles in startups is that it does not always stay in its lane. I took the responsibility expecting to just manage software projects since that was the world I already knew, but as soon as the software was ready for launch, the scope of my responsibility expanded quickly, and it expanded in directions I did not anticipate. At different points, I have been responsible for hiring pipelines, operational workflows, and even marketing campaigns. At all points, I wasn’t just overseeing the work from a distance. I was actively in it, sitting in interviews, writing briefs, reviewing vendor contracts, cold-calling, and pushing campaigns.

This responsibility strong-armed me into a crash course on different parts of running a business that I would normally never have to worry about as a developer. In Hiring, for example, it turns out that the experience that allows me to read code and find bugs does almost nothing for me when trying to tell whether someone is actually going to be a good fit on a team. Operations had its own lesson too: like code, so much of what keeps things running on the surface is invisible until it breaks, and the moment you stop paying attention to it, things start falling apart fast. Marketing taught me that being right about something and being able to make people care enough to listen are two completely different skills. 

Having been in leadership positions in the past, I was familiar with what leading from expertise looked like, but roles like this put you in a totally new situation, one where you may not have sufficient knowledge on the topic. That absence of knowledge forces you to actually listen, to make everyone understand and have interest in the big picture,  instead of just issuing directions, and to make space for people to do their best work without you getting in the way. 

Achieving this required me to drop a certain kind of performance. I could not lead by projecting expertise I did not have. What I had to lead with instead was clarity about direction, genuine curiosity about the perspective of team members, and enough honesty to say, "I think this is the right call, but tell me what I am missing."

That meant becoming a student again instead of playing the expert, and since I consistently had to make decisions in areas where I genuinely didn't have the depth, I put on my student hat. I read, took classes, and asked questions that probably revealed more about my gaps than I realized. That turned out to be a better leadership posture, and it's a big part of how the hiring, operations, and marketing tasks actually moved forward.

The honest realization of what this experience has done to me is that it has made me much less particular about being the best. I used to carry a lot of anxiety around not being the best at whatever I was doing. That anxiety is mostly gone now, replaced by something that feels more like appetite. I want to be in rooms where I am not the smartest person. I want to take on things that I do not already know how to do because I have now seen firsthand that the growth that happens in unfamiliar territory is much different in quality from the growth that happens when you are just getting better at things you already understand.

There is also something specific that this experience has clarified about software development, which is the field I will eventually go back to. I understand now what it means for engineering work to actually serve a business, and not just function technically.  I have been on the other side of the table, trying to explain timelines and translate technical debt into business risk to stakeholders who demand five critical new features delivered in the time it takes to build one, and to make a case for investment in infrastructure to people who only see what ships. This new context is going to make me a better engineer, a better technical lead, and a better collaborator than I was before I left.

If you are someone who is good at what you do and someone offers you a chance to lead something you are not already good at, my honest advice is to take it seriously. The discomfort is the point. Learning is both part of the job and the result of doing the job. And the version of yourself that comes out on the other side of voluntarily accepting genuinely hard, unfamiliar responsibility is more useful, more adaptable, and more interesting than the version that only wants to stay in familiar territory.