4 ms·

> When asking engineers how long it takes for a new hire to get up to speed, a common response is six to twelve months. Not sure where the stats are from. In m

> When asking engineers how long it takes for a new hire to get up to speed, a common response is six to twelve months. Not sure where the stats are from. In my experience it is much shorter, like a few weeks max.

yurishimo 4y ago
I think it highly depends on the company and product you’re working on. If you come into an agency as an IC to be rented out as a consultant, sure it’s easy to onboard because you’re essentially doing greenfield. Currently I work for a large org doing 100M+ of online revenue. I work on a team that builds tools for internal staff to manage orders. Our business is also somewhat seasonal. If someone onboards in February, its not uncommon for them to be unfamiliar with the seasonal parts of our codebase because they are only used 2 months of the year. Will they be contributing code and closing tickets in a few weeks? Yes, but they won’t be confident about the flow of the entire application and all the real world gotchas until working through at least one holiday cycle, if not two.
Xylakant 4y ago
That really depends on the complexity of the app/environment in question and on the definition of “up to speed”. If you consider it sufficient that the hire can contribute code changes, then a few weeks is probably enough. If having a good model of a moderately complex environment is the goal, a few month doesn’t sound off.
Joel_Mckay 4y ago
Depends, but in general: "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure" ( Melvin E. Conway, https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law)
BlargMcLarg 4y ago
It's a bad saying either way. It's too context-sensitive and riddled with semantics to draw anything of use from. Sibling comments already showcase this. Not only that, it doesn't take into account you don't jump from 0 to 100 in a single go. It's more of a curve where you'll be decently productive early in the journey, and spend most of your time getting the remaining 20-10 figured out. And with most companies generating pretty decent profits, I'd wager being halfway your full productivity is already close to a net profit for most established companies, which negates the entire "the company runs at a loss for several months!" spiel. That's not to mention that saying makes it very easy for companies to deflect responsibilities onto ICs, as if expecting everyone to know everything is "just how it should be".

yurishimo 4y ago

I think it highly depends on the company and product you’re working on. If you come into an agency as an IC to be rented out as a consultant, sure it’s easy to onboard because you’re essentially doing greenfield. Currently I work for a large org doing 100M+ of online revenue. I work on a team that builds tools for internal staff to manage orders. Our business is also somewhat seasonal. If someone onboards in February, its not uncommon for them to be unfamiliar with the seasonal parts of our codebase because they are only used 2 months of the year. Will they be contributing code and closing tickets in a few weeks? Yes, but they won’t be confident about the flow of the entire application and all the real world gotchas until working through at least one holiday cycle, if not two.

Xylakant 4y ago

That really depends on the complexity of the app/environment in question and on the definition of “up to speed”. If you consider it sufficient that the hire can contribute code changes, then a few weeks is probably enough. If having a good model of a moderately complex environment is the goal, a few month doesn’t sound off.

Joel_Mckay 4y ago

Depends, but in general: "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure" ( Melvin E. Conway, https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law)

BlargMcLarg 4y ago

It's a bad saying either way. It's too context-sensitive and riddled with semantics to draw anything of use from. Sibling comments already showcase this. Not only that, it doesn't take into account you don't jump from 0 to 100 in a single go. It's more of a curve where you'll be decently productive early in the journey, and spend most of your time getting the remaining 20-10 figured out. And with most companies generating pretty decent profits, I'd wager being halfway your full productivity is already close to a net profit for most established companies, which negates the entire "the company runs at a loss for several months!" spiel. That's not to mention that saying makes it very easy for companies to deflect responsibilities onto ICs, as if expecting everyone to know everything is "just how it should be".