What Got Me Here Wouldn't Get Me Further

For a long time, I took a lot of pride in being able to figure things out on my own. I was mostly self-taught, so independence became part of how I saw myself as an engineer. If I didn't understand something, I would read until I did. If a problem looked complicated, I would keep digging until I found a way through it. I rarely wanted to ask for help before I had exhausted every option myself.

That mindset served me well for years. It made me resourceful. It taught me how to enter unfamiliar codebases without much guidance, how to work through problems that didn't have an obvious answer, and how to become productive without needing someone constantly pointing me in the right direction. But somewhere along the way, independence also became part of the image I wanted to project.

I wanted to be the engineer who knew what he was doing. The one who could take something difficult, disappear for a while, and come back with it solved. I had strong opinions, probably more often than I should have, and I was proud of not needing much help. Looking back, I was probably a little cocky too.

Not necessarily in an intentional or malicious way. I don't remember walking into rooms thinking I was smarter than everyone else. It was subtler than that. Competence and independence had become so closely connected in my head that asking for help, changing my mind, or admitting I didn't know something sometimes felt like weaknesses. And as an individual contributor, you can get surprisingly far that way.

When independence stops scaling

The problem became clearer as my responsibilities grew. The more senior I became, the less often the hardest problems were problems I could solve entirely by myself. They involved systems I only partially understood, teams with context I didn't have, decisions made years before I arrived, product constraints, deadlines, competing priorities, and technical trade-offs where several reasonable people could reach different conclusions.

Being able to write the code was still useful, but it wasn't enough anymore. There were situations where the fastest way forward wasn't to disappear and figure everything out myself. It was to ask someone who already understood that part of the system. Sometimes the right thing was to bring people into a decision earlier instead of presenting a nearly finished answer later. Sometimes someone else's suggestion was simply better than mine. And sometimes the most valuable thing I could contribute wasn't an implementation at all, but helping a group understand the problem well enough that someone else could implement the right thing.

None of those behaviors fit particularly well with the lone-wolf version of engineering I had spent years reinforcing.

The uncomfortable part about becoming Staff

I don't think becoming a Staff Engineer suddenly taught me this lesson. It was more that the role made it harder to ignore. At that level, your effectiveness depends much more on what happens around you.

If every difficult problem requires you personally to solve it, you're creating a bottleneck. If people are hesitant to challenge your ideas because you always sound certain, you're probably losing useful information. If you enter every discussion trying to demonstrate that you understand the problem instead of trying to understand what everyone else knows, you're leaving context on the table. And if the team only succeeds when you're the person doing the work, that's not really leverage.

This changed the way I think about technical strength. Earlier in my career, I often associated strength with having answers. Now I think it has just as much to do with asking good questions, recognizing when someone else has better context, creating space for disagreement, and being comfortable saying, "I don't know yet." That last one took me longer than I would like to admit.

Some habits take longer to unlearn

One thing I've found interesting is that changing how you behave and changing how people perceive you are two different things. I've been consciously working on this for a while now. I try to listen longer before forming an opinion. I ask for context sooner. I try not to jump into every discussion just because I have something to say. When someone has stronger knowledge of a system than I do, I try to treat that as an advantage rather than something I need to compete with. I also ask for help much earlier than I used to.

Personally, I think those changes have made a noticeable difference. But reputation has inertia. If you've spent years presenting yourself as the person who always has an answer, people learn to interact with you that way. If you've been overly independent, people stop assuming you want to collaborate. If your opinions have historically arrived with too much certainty, people may hesitate before challenging them.

You don't undo that with one conversation. You have to behave differently consistently enough that people eventually build a different model of you. I think that part is easy to underestimate.

Being self-taught had a downside I didn't recognize

I've sometimes wondered whether I would have learned some of this earlier if I'd had more deliberate mentorship. Being self-taught was incredibly valuable to me technically. It gave me a strong instinct for figuring things out and made me comfortable entering situations where I didn't know what I was doing yet. But there was also a downside.

When you're teaching yourself programming, the feedback loop is relatively clear. The code works or it doesn't. The application crashes or it doesn't. You can read documentation, inspect another implementation, run an experiment, and eventually work your way toward an answer.

The social side of engineering is much harder to teach yourself. Nobody tells you that the way you're presenting an idea is causing someone else to disengage. There's no compiler warning when you're dominating a technical discussion. You don't get a failing test because someone stopped bringing you half-formed ideas because they expect you to immediately point out what's wrong with them.

A good manager, mentor, or experienced teammate can sometimes show you those things much earlier. I didn't always have that. That doesn't excuse bad behavior, but I do think it helps explain why some lessons took me longer to recognize.

I wouldn't remove the independence

The strange part is that I don't actually want to lose the person who learned to solve problems alone. That part of me is still useful. There are still plenty of situations where nobody has the answer, documentation is incomplete, the system is unfamiliar, and someone needs to keep digging until things make sense. Being comfortable in that environment has been one of the most useful skills of my career.

The difference is that I no longer think independence is the goal. It is a tool. Sometimes I should go deep by myself. Sometimes I should ask for help immediately. Sometimes I should lead the decision. Sometimes I should support someone else's. Knowing which situation I'm in matters more than proving that I can handle all of them alone.

For a long time, I thought becoming a stronger engineer meant needing other people less. The further I moved in my career, the more I realized almost the opposite was true. The problems got bigger than what one person could hold in their head, and being effective started depending much more on how well I could work through those problems with other people.

A lot of what got me here is still valuable. I just had to stop treating it as the only way to move forward.