4 ms·

Do you have any idea the amount of effort it takes to train 36 people? Not only that, but it would cost payroll for X months PLUS the cost of training, with unc

by jiofih 5y ago

Do you have any idea the amount of effort it takes to train 36 people? Not only that, but it would cost payroll for X months PLUS the cost of training, with uncertain results, and they would still start with zero working experience. Hiring is a much better, less risky filter. Companies are not families with irreversible bonds, and everyone, especially employees, are better off acknowledging that.

mgkimsal 5y ago
"Do you have any idea the amount of effort it takes to train 36 people?" It takes a long time for new people to have a real understanding of the current system, the tradeoff decisions and culture that led to the current system. And it takes a long time for new people to learn how to work effectively together. I'd think bringing in new leadership and product vision first, and having the existing team be given the go ahead to work towards those new goals should be the first step, only doing large scale replacements if they don't deliver. Loads of people will point to the Spolsky "iterate, don't start from scratch" story about netscape. Replacing large parts of your engineering team vs just improving the team you have seems like the same "mistake". Also not sure how they have such a large team in the first place, but that may be part of the root reason. I don't just mean large engineering team - google is showing ~200 employees altogether, which just seems like a lot, but many of those might be CSR positions? But I suspect this is all to do with bringing in much cheaper people.
- viraptor 5y ago
  Without looking too deep at the list of positions, it doesn't seem unreasonable. They're in a market where they have web and app presence, have to deal with international recurring payments and deposits, have to deal with global support and disputes, likely need a decent fraud team since they accept tiny payments, need to handle abuse and scams, etc. These roles add up quickly.
mutant 5y ago
So upending the lives of 36 dedicated employees is the best alternative? People can't raise money like a corporation can. Those people got the company to where they are today, so suddenly it's fine to just cut them loose because you made a video about how you feel about the situation?
- viraptor 5y ago
  How much of a problem is it right now to find a tech job in SF? Considering they got 3mths pay + extra early stock + insurance coverage it's not a great place to be in, but it doesn't seem terrible. (I've been in a similar situation in the middle of nowhere and can't really complain about the outcome.)
- jiofih 5y ago
  It’s a job, not a relationship. In fact, in the US it’s fine to cut people loose at any time for no reason at all. Whatever they get as severance or even an explanation is out of the employers goodwill. Don’t like it? Vote better.
specialist 5y ago
> Do you have any idea the amount of effort it takes to train 36 people? Two weeks? Certainly less time than it'll take to restaff and onboard their replacements. It's a website. Web stacks are mayflys. Pivoting to today's new hotness is part of the gig.
- jiofih 5y ago
  I used to organize corporate trainings. A basic [language here] one would take 2 weeks and barely get people comfortable with what they learned. You could do more with an intensive format of 40hrs/week, but to think you can train people in two weeks for completely different roles an have them come out effective employees is just... wishful thinking to be polite. If that was possible you’d see your peers changing career all the time to chase higher pay. The closest thing would be a bootcamp which usually are 3-6 months long, and again, doesn’t make up for the lack of work experience. Also we have no idea what kind of switch this would be about, so it’s pure speculation on your part.
  - specialist 5y ago
    Sure. 3-6 months is usual for new hires, retraining. For comparison, I onboarded ~20 domain experts, pushing real code to prod in 1 week, unsupervised in 2. New language, new tooling, new stack, new specs, new clients. YMMV. > ...pure speculation on your part. Heh. Our part. After that CEO's video, I'm completely comfortable to assume more of the same.
    - jiofih 5y ago
      When I say speculation, I mean regarding what retraining would entail. You’re assuming a simple switch in technology stack, when in reality there are varying degrees of difficulty in switching roles (eg web to native mobile development, FE dev to payment infrastructure, CRUD apps to high perf networking, and so on), some of which require years in experience to be effective. Or maybe they need 36 marketers instead, you can’t really “retrain” for a new BsC. There’s really no reason for a company to take the risk of “hiring” 36 juniors other than a vague sense of the company being indebted to them - which they’re not, if employees were well compensated and treated fairly. It’s a business relationship. You don’t owe them, they don’t owe you anything.
unity1001 5y ago
A senior dev could get into a new stack reliably within ~3 months. And it doesnt 'take' effort to train them - they just do it themselves. And the cost of loss of people who know the existing product, business model, existing codebase is WAY too great than a few months' pay. That's something that comes only by having people on board for long duration and having them accumulate experience of the existing product and business model. Most people from MBA background has little understanding of this. They tend to see engineers as replaceable - you just bring in someone who knows a new stack while passing to that new stack and youre done (the best case scenario). It doesnt work like that. When you lose experienced engineers who know the product and the codebase in a fast moving startup, you lose people who you need to ask stuff when you need to do something new. Especially when the codebase lacks sufficient documentation (common in startups). Then the newcomers have to learn the codebase all over again - a gigantic hit to productivity. This is why people from non-engineering background should not make engineering hiring/firing decisions.

by jiofih 5y ago

mgkimsal 5y ago

"Do you have any idea the amount of effort it takes to train 36 people?" It takes a long time for new people to have a real understanding of the current system, the tradeoff decisions and culture that led to the current system. And it takes a long time for new people to learn how to work effectively together. I'd think bringing in new leadership and product vision first, and having the existing team be given the go ahead to work towards those new goals should be the first step, only doing large scale replacements if they don't deliver. Loads of people will point to the Spolsky "iterate, don't start from scratch" story about netscape. Replacing large parts of your engineering team vs just improving the team you have seems like the same "mistake". Also not sure how they have such a large team in the first place, but that may be part of the root reason. I don't just mean large engineering team - google is showing ~200 employees altogether, which just seems like a lot, but many of those might be CSR positions? But I suspect this is all to do with bringing in much cheaper people.

viraptor 5y ago
Without looking too deep at the list of positions, it doesn't seem unreasonable. They're in a market where they have web and app presence, have to deal with international recurring payments and deposits, have to deal with global support and disputes, likely need a decent fraud team since they accept tiny payments, need to handle abuse and scams, etc. These roles add up quickly.

mutant 5y ago

So upending the lives of 36 dedicated employees is the best alternative? People can't raise money like a corporation can. Those people got the company to where they are today, so suddenly it's fine to just cut them loose because you made a video about how you feel about the situation?

viraptor 5y ago
How much of a problem is it right now to find a tech job in SF? Considering they got 3mths pay + extra early stock + insurance coverage it's not a great place to be in, but it doesn't seem terrible. (I've been in a similar situation in the middle of nowhere and can't really complain about the outcome.)
jiofih 5y ago
It’s a job, not a relationship. In fact, in the US it’s fine to cut people loose at any time for no reason at all. Whatever they get as severance or even an explanation is out of the employers goodwill. Don’t like it? Vote better.

specialist 5y ago

> Do you have any idea the amount of effort it takes to train 36 people? Two weeks? Certainly less time than it'll take to restaff and onboard their replacements. It's a website. Web stacks are mayflys. Pivoting to today's new hotness is part of the gig.

jiofih 5y ago
I used to organize corporate trainings. A basic [language here] one would take 2 weeks and barely get people comfortable with what they learned. You could do more with an intensive format of 40hrs/week, but to think you can train people in two weeks for completely different roles an have them come out effective employees is just... wishful thinking to be polite. If that was possible you’d see your peers changing career all the time to chase higher pay. The closest thing would be a bootcamp which usually are 3-6 months long, and again, doesn’t make up for the lack of work experience. Also we have no idea what kind of switch this would be about, so it’s pure speculation on your part.
- specialist 5y ago
  Sure. 3-6 months is usual for new hires, retraining. For comparison, I onboarded ~20 domain experts, pushing real code to prod in 1 week, unsupervised in 2. New language, new tooling, new stack, new specs, new clients. YMMV. > ...pure speculation on your part. Heh. Our part. After that CEO's video, I'm completely comfortable to assume more of the same.
  - jiofih 5y ago
    When I say speculation, I mean regarding what retraining would entail. You’re assuming a simple switch in technology stack, when in reality there are varying degrees of difficulty in switching roles (eg web to native mobile development, FE dev to payment infrastructure, CRUD apps to high perf networking, and so on), some of which require years in experience to be effective. Or maybe they need 36 marketers instead, you can’t really “retrain” for a new BsC. There’s really no reason for a company to take the risk of “hiring” 36 juniors other than a vague sense of the company being indebted to them - which they’re not, if employees were well compensated and treated fairly. It’s a business relationship. You don’t owe them, they don’t owe you anything.

unity1001 5y ago

A senior dev could get into a new stack reliably within ~3 months. And it doesnt 'take' effort to train them - they just do it themselves. And the cost of loss of people who know the existing product, business model, existing codebase is WAY too great than a few months' pay. That's something that comes only by having people on board for long duration and having them accumulate experience of the existing product and business model. Most people from MBA background has little understanding of this. They tend to see engineers as replaceable - you just bring in someone who knows a new stack while passing to that new stack and youre done (the best case scenario). It doesnt work like that. When you lose experienced engineers who know the product and the codebase in a fast moving startup, you lose people who you need to ask stuff when you need to do something new. Especially when the codebase lacks sufficient documentation (common in startups). Then the newcomers have to learn the codebase all over again - a gigantic hit to productivity. This is why people from non-engineering background should not make engineering hiring/firing decisions.