I was initially thinking about the classic nature/nurture tradeoff based on your title, but by the end of your story, I see you're speaking to something far more important: the value of failure.

The short answer is: Yes, everyone falls. And then you get to learn how to pick yourself up.

Sorry to say, but your story is more mundane than you're making it sound. Everybody falls. You got to see firsthand how a low-support environment and an overly-emotional "leader" can completely fail to capture value from a provably skilled and valuable employee. And then, right after, you got to see the value of trusting your instincts, having good relationships, being on a team where you feel psychologically safe and feel like you truly belong.

Yes, you were a little bit lucky — specifically, your luck was that you got a good job immediately, whereas plenty of people (including folks more senior than you) sometimes get hit by bad luck in the job search process. But you would've found a good job sooner or later, so I wouldn't chalk up too much to luck.

Overall, you got to do some growing up, and it will serve you incredibly well in the long run.

Consider: How differently will you approach the next engineer you mentor? How differently will you deal with stakeholders now? How differently do you feel about the importance of onboarding, of second chances, of objective performance-review processes?

Every misstep has a dozen lessons we can extract. I'm impressed by how quickly you picked yourself back up. I hope you set aside some time to reflect and extract all the valuable lessons, too.

Thanks for these valuable insights, please can you elaborate on the "trusting your instincts" in this context?

In all honesty, I was primarily echoing OP's bit where they said, "I'm just using my gut and it's going swimmingly."

More broadly, this kind of thing often makes me think of the idea of "self-reliance" [1]. In other words, the accumulation of career experience parallels the gradual process of learning to trust yourself and your (ever more finely honed) instincts more and more.

[1]: https://archive.vcu.edu/english/engweb/transcendentalism/aut...

The problem at company B was everyone was experienced so they haven’t needed to onboard anyone. As a result you had no onboarding and that’s a team failure. I tell new joiners their fresh feedback is the most important thing they can contribute when they start and we place a lot of value in a smooth onboarding.

The result of not doing that is that people are taken off their work to help the person onboard manually. This then can cause the feeling they’re being held up as you experienced, this is where a true senior would have noticed this issue and raised it. It seems none of the team members were actually behaving like a senior.

Unfortunately this wasn’t explained to you so you felt disempowered to feedback on your experience so the next person they hire will have the same problem.

So on a successful onboard you might produce a better onboarding experience for the next person plus a bunch of feedback on the product with fresh eyes that many new customers will share.

Glad it worked out at a new place!

I think this is a great question that deserves a book-length response.

Instead I will say, yes absolutely, environment is everything. We are like the dust on the wind. This is important in our careers, but also in our personal lives and everything we strive to do. The fastest way to change yourself is to change your environment. Whoever said "wherever you go, there you are" was dead wrong in my view. A great environment can bring out the best in the worst of us and a bad environment can turn the best of us into villains.

I have experienced going from the front of the pack to the back, then the reverse several times in my career. And the back of the pack is soul destroying. It obliterates your confidence and with it, your competence. A friendly environment can build up even the most junior team member and a hostile environment tears everyone down.

It's not you. You are great and worthy and you should always take yourself where you will be most appreciated.

There was a miss in the expectations from the beginning.

“I was hired as junior and I’m expected to contribute from the off;”

That’s language for being setup to fail. Anyone who hires a a junior engineer or even early mid level and expects quick ramp up, fully flushed designs, instantaneous tickets being finished is delusional and, in my opinion, not fit as a lead at all.

When a junior is brought onto my team 1. I don’t expect them to know anything, they need to learn all of it and sometimes it takes multiple attempts 2. They are not in charge of designs, they take well defined tickets to completion 3. If it fails in production it’s my fault, they need breathing room to make mistakes 4. My ROI horizon is 6 months to a year

Shaming someone for failing never works. If it doesn’t work for important stuff like parenting why would it ever work in a corporate environment.

End of rant

Not necessarily "mismatch" or "being setup to fail", it depends entirely on how much mentoring, hand-holding, code-review, test, documentation, wikis etc. there is. Onboarding and managing new hires is a key component of a healthy company culture. Lots of companies pay lip-service to this, few walk the walk.

> Shaming someone for failing never works.

It's perfectly ok to fail (otherwise you'll never learn), and shouldn't result in them getting punished or summarily losing their job, but the person simply needs to show they learned from their mistakes (and there needs to be a culture which actively rewards sharing knowledge and enables people to learn, not just blamestorming or hazing). For example, a company not having a wiki/ Slack channel/ internal/ departmental mailing-list where such stuff can be safely and frankly discussed, and gets meaningful constructive non-backstabbing responses, is a bad sign. But it's common.

I suspect you already know the answer here.

The organization, culture, and fit with the role are massively important to your success.

What you're describing in Company B sounds like a failure of hiring process, management competency, or both.

A well-designed hiring process should give both the company and candidate a clear idea of how well they will match with the role. While there are people who interview well and underperform, a good hiring process should really catch most of those. This is one of the things that distinguishes true HR professionals from the amateurs.

As a candidate, you want to ask the right questions to understand what's expected of the role. This can include examples of the kind of projects/tickets you'd work on, as well as the overall pace and vibe of the team.

Provided that the new employee is in the general ballpark of what's expected for the role, their managers should help them succeed, communicate clear expectations, give specific and constructive feedback, and provide the resources for them to adjust to, and succeed in the role.

I think you're also discovering the differences that can exist in leveling between companies. What is expected of a senior engineer at one company could be intermediate at another and so on.

It can be worthwhile to reflect on this experience to look for clues you may have overlooked in the hiring process. Sometimes those clues can be subtle and other times they can be hard to miss. Similarly, it can be beneficial to think of questions you could ask when interviewing in the future to help identify dysfunctional or toxic culture.

For what it’s worth, I recall one factoid from some planet money episode a long, long time ago, that the quality of a supervisor determines roughly 75% of your overall performance. Unfortunately, I cannot cite the episode nor can I cite the source within that episode. If I had to take a guess, it was someone from Harvard business school. The reason why I remember that number rather is because it fits right in line with my experience.

I was much younger in my career then, after after learning that, I immediately had zero tolerance for bad management. It was clear that the only way out was to either jump ship or get your existing manager out of your hair. That’s when it’s crucial to manage upwards. With even bad managers, if you can figure out their motivations, then you can figure out a way for them to leave you alone.

Reading this I think I understood what's behind "some tangential thing is majority of success" claims: it is multiplier, not percentage of absolute level.

"One can be 4x more performant when led by empowering rather than bureaucratic boss" is plausible. "Unskilled, slacking person will achieve nearly as much as skilled one in same team" is questionable.

Decades ago, HBR described a study suggesting that CEOs do not have portable talent, if not followed by their team.

There’s a phrase I heard in the military: “treat him like a child and he’ll act like a child, treat him like an adult and he’ll act like an adult.”

You saw this from time to time where a soldier would just fuck up everything. Their “boss” would start treating them like a child, never trusting them to do something right, always watching them like a hawk, etc. Unlike the civilian world, you can’t just fire someone, so there was quite a bit of shared experience in handling these types of situations. Eventually someone would notice and tell the “boss” that phrase. The “boss” would force themselves to trust the person, to let them make their own mistakes just like an adult. The “trouble-child” would miraculously start performing so much better in 99% of cases. It was like magic.

I’ve been on both sides of that coin in my short 5 years in the military, but I see it from time to time in the tech world too. Unless there’s someone around who knows how to fix it, it will spiral out of control like you saw.

I love how thoughtful you are about everything you wrote!! I'm about 6 years into my career but have jumped across 5-6 companies already counting internships..

My experience is a lot like yours. I've performed _incredibly well_ at one company. In 1 year, got 2 big promos, a small team under me and respect of the CTO. I straight up burned out, showed up late to work and got dumpstered in 3 months at the worst. Did varying levels of good/bad at others. Each time it all felt very personal until i get some distance and see that yes, it was personal but it was also environment and i can only change so much so quickly.

Honestly my belief is now that environment is 80% of performance. The tech skills they need, the way you gel with teammates, the little chances you make or break at the beginning and how that snowballs into trust or distrust among a team, how aligned you feel with the mission, maybe even the noise level at the office or the quality of the dev laptop and environment... every little thing counts so much. Its hard to even know what will count.

All i can say is yeah i agree, it a deep question i think about too and keep up the work to really reflect on what environments suit you and how to suss them out from interviews.

I've seen people that were killing it in one company move to another company and be just another developer. You can even see this when people move around in the same company.

People introduced into a new group tend to converge on a different role in that group. It's part of group dynamics and human nature. This is why it's really important that managers set up their team to be successful and why you can't really judge performance of someone without context. If you don't give someone the right conditions to be successful (as a manager) that's on you and not on them.

That said there is always a mix of factors in play.

Maybe company C is closer to your comfort zone in company A and company B was different enough that it actually was hard to perform at a high level? I'm not getting very good vibes though from your description of company B (though there's always two sides to a story).

I had the same experience as you in your company B, and as someone with 20 yrs experience who worked for enterprise, but mostly joined/founded startups -

Expecting someone to contribute day1 is bad mentality, proof of bad management.

Bad CTOs and Tech Leads can't understand that they hold knowledge of years building the code estate (while often skipping documenting it), which is difficult for newcomers to accuire.

Just setting up the machine can take 2 weeks.

And they are in their own echo-chamber, thinking every choice they made is the right one and must be used everywhere.

"What? you never used tool A? It's what we use everywhere". Well good for you! I used tool B, C, Z, X, A7, and forgot most of them. Don't give me these looks!

And of course, working in such conditions you can't improve. They exclude you from discussions, give bad looks and comments, and completely erode your confidence.

You might not be the best, but they are definitely worse.

> Expecting someone to contribute day1 is bad mentality, proof of bad management. Bad CTOs and Tech Leads can't understand that they hold knowledge of years building the code estate (while often skipping documenting it), which is difficult for newcomers to accuire.

Getting up to speed quickly in that sort of situation can be difficult, but it's not impossible. However it's a skill that requires development just like any other. If you've never done it before you will likely struggle the first few times, but get better over time. I don't agree this is _just_ bad management... but rather a mixture of that and just misaligned expectations and background. It could certainly have been handled better, but saying that expecting a quick ramp up is proof of bad management is a bit too far in my mind.

There's no such thing as developing the skill to install / configure misc undocumented services, requirements, etc. "Oh, you have to set xyz environment variable in dev for this db to work", "Yeah, the documentation for that was before we migrated to typescript", etc. If you expect new team members to contribute it is your responsibility to give them a functioning environment.

There absolutely is. This is a skill i take pride in - being able to run into a random failure and dig through logs, exceptions, code etc. to figure out what is missing.

Being able to quickly understand and debug a large vertical slice of a system across many layers like that without docs or handholding is really valuable in a broad SRE/production engineering type role or a do everything early engineer type role when docs/handholding are in short supply.

Not to say you have to have it. Many engineers are bad at this but way better at consistently putting out solid bug-free code quickly than me and thats a huge chunk of engineering as well.

But it is a learnable skill. 90% is honestly just reading errors carefully, googling them and following the trail but many people have sort of a panic/ignore response when a weird looking error messsage comes up somewhere and interrupts the flow.

> This is a skill i take pride in - being able to run into a random failure and dig through logs, exceptions, code etc. to figure out what is missing.

And your manager wanders over and sees you haven’t written a single line of code in the last three hours and makes a mental note that you might need a kick in the pants to get up to speed.

I’m pretty good at hunting bugs but once in a while I just can’t figure out why something isn’t working and if I had to worry about being “that guy” because I had to ask for help I’d…well, things would go really bad really fast.

Assuming the OP didn’t overly exaggerate their skill set to get the job that place sounds like a nightmare to work at.

I don't know why you feel the need to shit on my calling it a skill. Yes asking for help is important too when you don't need to do this, particularly as a junior. But some times you are the guy who others come to asking to for help and are the one who has to figure it out.

For sure this is a learnable skill. I made Linux packages for open source projects that were not my own, and definitely learned a lot about this. If anyone wants practice today, go set up a bunch of random GitHub projects.

I played basketball as a teenager. One year, I was in the starting lineup. The coach believed in me and was vocal about it. He gave me clear feedback, both positive and negative. Overall, I played well and was improving quickly.

Next year, the coach got replaced. The new coach benched me and gave me no feedback. Though he didn’t say it, it was obvious he didn’t believe in me, for whatever reason, justified or not. I started playing worse, which only reinforced his view, and then my minutes went down, which gave me less opportunity to improve, which reinforced his view further, etc. I was still on the same team but I wasn’t the same player. I was but a shadow of the player from last year.

Whether the new coach was right about me or not, I will never know. Was I falling behind because others were improving faster or because I internalised his lack of trust? Maybe I wasn’t as promising as I had thought and he merely saw it or maybe he was unjust. Whatever the reason, he ended my basketball career that year (though it would take a few more years for me to realise it).

As a young basketball player, your window of opportunity to develop is small and, if you miss it, you’re basically done. As a young software engineer, you have more than enough opportunity to find a better team and, more importantly, a better coach.

> there's no documentation to set stuff up

This is very common, and it can ruin a new hire for no reason (as well as lead to problems later, when it turns out everyone is doing various cargo cult ways of running the code). Almost everywhere I've worked, if there was existing code, there was key undocumented info that was necessary to get the code, build, and run it.

It's become the norm for me, when starting at a new place, to grab someone who knows how to get and run the code, and have them walk me through it while I take step-by-step notes, then I turn that into the start of the official development docs. (I'll also start capturing other org process information, usually starting with things like what comms are used for what, who to talk to about common things, how to use a wiki effectively, etc.)

This is exactly the way to go. It will unblock yourself, and improve things for future team members.

Environment makes a big difference, and environmental changes that make a huge difference can even be much smaller than it seems. I once worked at at a place where I spent years in the same team, always as a dev lead, but with rotating managers. The difference between a review in the top 5% that comes with a big bonus and being marked as needing major improvement can be just a lone manager change and 3 months.

It's not that startups ask for more, and corporate jobs for less: Teams and expectations vary wildly, even within the same department of a big company. There are startups that take two weeks off for christmas, and others where they fire new people ever 5 months, and think that 996 is a good schedule. You could be mentored and helped, or left to dry.

And it's not even that expectations of early contributions are a problem: I've had great success expecting contributions on literal day 1, from people right out of school... but the tasks were planned long before, as we saved tasks for onboarding when we knew there was someone coming soon. Nothing like showing a new person that they can make some quality of life improvements to the team's tools, and see how the entire team gets to keep using them, many months later.

Employee on-boarding success is 90% preparation from the people leading the team and setting expectations. If my new hire is overwhelmed, and can't do what I ask them, I failed them far more than they failed me. But in an industry like ours, we rarely think about onboarding, teach the skills to do it well, or reward people that are being successful. In some cases, it might even be the other way around: Add some stack ranking, and a good part of the team might be better off if you struggle and get the worst review. Other times leads just got there by getting a lot of code written, but haven't had to bother for a second about how other people are feeling, and how to help them be more productive.

So be kind with the people that aren't any good at this, and try to learn how this is done well, just so that when you are in a position to help a new team member, as a lead, mentor, or just onboarding buddy, you can make sure you don't end up giving people the Company B treatment

All I can say is that it seems as if you are measuring your own performance not as an absolute, but as relative to where someone else has arbitrarily placed the bar. The only thing you should ever be measuring yourself against is your younger self.

This question could be an entire series of answers, but yes, the environment absolutely contributes to ones performance.

Not only in explicit ways such as availability of resources, supportive processes, and the cognitive comfort of being within an environment where things "make sense" to you (ie, you can operate on your instinct with confidence), but also in implicit ways that impact your internal motivation.

I've definitely been in positions before where a culture shock of environment change led to me being unmotivated, as well as just making stupid mistakes that I wouldn't have made previously. I've had previous coworkers that I would definitely consider hiring again as long as it was not back into the same environment I previously worked at them in, and had coworkers that were fantastic previously but I honestly wouldn't expect to have the same level of performance in a different environment.

Success in your career is not just about your skills (both hard and soft), but about finding an environment which is conducive to your particular skills and working style.

I believe that environment counts a lot and it sounds like that is what happened to you. I remember a long time ago, hearing about a study done in Math classrooms where the teachers expected the boys to do better than the girls and that is what happened. Simultaneously, they had a Math teacher who expected all of their students (boys and girls) to do well and that is what happened. Part of leadership is believing in the people who work with you. They need to create an environment where everyone can be successful. The people in that environment need to tolerate mistakes. Senior developers need to have an attitude that if other developers mess anything up, it's because of knowledge or skill and that the person is doing their best. Then do what is necessary to help that person overcome their weaknesses. That said, there are people beyond help for various reasons. However, the majority of people I ever worked with want to do a good job. I've been in that situation before too and learned that the best think to do is start a new job search right away.

In my case:

Limiting case 1: I worked in an office before coronavirus and was well respected as a lead contributor. Smashed all of my reviews, went contracting, fantastic.

Limiting case 2: during coronavirus I was the only person in the office. This company culture eventually made me lose my sanity to the extent that I had to seek help. I couldn't work at all, 0% productivity.

For me it's obvious that environment matters.

The short answer is absolutely.

While one can dedicate their whole life towards the commonly misattributed quote "If you're the smartest person in the room, then you're in the wrong room". There's just ebbs and flows to life where one day you're on-top of the world and another looking up a cliff.

One of the best books on this phenomena is "Flow: The Psychology of Optimal Experience". Needless to say, the core idea is that you can cycle between states of anxiety and boredom depending on arousal and efficacy of the skills and challenges you have. The sweet spot i.e. Flow state is the "just right" spot in-between where you are challenged enough and uses your skills effectively.

The more you enter the flow state, the more you train your ability for insight.

So when I see posts like this, you are either on one side of anxiety and boredom. What you desire is consistently being in the flow state.

Yeah, I’ve had a very similar dreadful experience once.

Didn’t get fired, just left myself after a while. They wouldn’t fire at the time, as the project required all hands on deck.

Still puzzling to me to be honest. I keep revisiting it in my head, but just can’t put my finger on what went wrong.

This is about being a fit or not.

Clearly you weren't a fit, which often times is barely related to your actually skill set.

Early in my career my bosses are people I would never hire today. This will be your future and you will look back at these people as silly at best.

My 2 years old new job in another top university but in a mediocre group kills my productivity. Dozens of irrelevant things and people to care about. I get blocked/saturated/tired and unable to pursue my own personal goals.

At company B, I think you really had to prioratize the right things to do and then the sub-option of how to not hold up other members (I.e. reverse engineer setup and document it) and start down that path..

Almost certainly they would have begun to decide that helping you along was a good tradeoff even if investing in getting you up to speed was a short term loss.

By skipping infrastructure you needed to do anything of adequate quality, they could pretend letting you get up to speed on your own worked and the eventual failure could be summarized as your repeated problems reaching expected quality.

I've had a very similar ride over the last couple of years. I can't help but feel that the environment you're in cannot do much to enhance performance, but it sure can make it worse. I also feel it has little to do with the company and more to do with which part of it you are in. I once worked for the same company twice - pretty good but with a shitty manager the first time, and really very bad the second. I'm now doing some honestly really great work for a bank of all things.

Company B failed at onboarding and level-setting. They didn't properly communicate what they wanted from you, didn't know that what they wanted wasn't a good fit and didn't know what training would be needed to fix it, and probably didn't even really understand what they wanted.

That sort of thing will be less common in companies with training and mentorship programs for new managers. Which I'd expect to correlate with startup vs bigco, but not be an exact match.

I have had trouble working remotely. I can be quite productive in an office (or rather a dev shop where people know when to be quiet), but 100% WFH has resulted in at least 2 job separations for me. So now I'm looking for partial WFH. You have to feel it out.

Some people are built for the corporate grind. Some are built for other things.

Startups are for learning, bigcos are for earning

> How much does the environment you're in contribute to performance?

As an oversimplified answer, a lot.

I think this is actually a complex question, cause there's a lot of dimensions to go in. Even in your story, it seems like your environment is influencing in many different ways. I'm gonna point out some things that stuck out to me (sorry if any of this is obvious/long-winded/not what you're looking for...).

Company A sounds mid to large sized, and it sounds like they hire a decent amount of college grads. Their size encourages them to have a reliable/smooth/consistent hiring and onboarding process. I would guess that there's a decent amount of tutorial/guide resources (e.g. code labs), as well as various system and process documentation. There's probably more support/guidance, and more senior team members have likely done their fair share of onboarding (so they're presumably better, more friendly, and more tolerant about it). As a result of all this, the learning curve probably feels a lot smoother and less steep.

Company B, as you mentioned, is likely expecting more significant contribution from the jump. A startup is probably not optimizing/focusing on training. But it's not just that--startups likely task people with larger and more vaguely defined tasks. Having prior, relevant experience to draw on is likely very helpful here, as it helps with defining and dealing with these more complex tasks. The learning curve is steeper and progressing along it feels much more unstructured and confusing. (If this is interesting, look into kind vs. wicked learning environments.)

Note that this has largely just been rough job expectations and approach to onboarding/training. There's still the whole people/social front.

It sounds like the experience with people at company B was unpleasant. To be charitable, maybe they were stressed, tired, low on patience, etc. Regardless, it seems like there was pressure to perform and not to fail. As I understand it, this kind of situation tends to make people perform worse (because they're stressed/tense/not able to focus as much on the task at hand). It's also not as conducive to learning since that requires some space to screw up.

I don't have much to go on for company C, but it sounds more collaborative/cooperative. I'm guessing that if/when you did propose a bad option for a design, your coworkers at least heard you out and justified why they thought it wouldn't work. They might also have recognized that you were making an effort to contribute and that, as a new hire, you were missing important information/context for making a decision.

So far this has mostly been one-sided: how your environment is likely to influence you. But you're still an actor here--someone's performance in an environment also depends on how they react to the environment! One person might prefer ambiguous tasks while another person prefers a clear set of instructions. Maybe one person handles stress really well while another feels like it's crushing them. Being able to recognize elements of your environment often makes it much easier to navigate, kind of like being at home vs. visiting somewhere foreign.

Anyways I've written a lot so I'll just leave it there. I hope it was interesting and not too much of a wall of text!