5 ms·

Why Startups Should Train Their People

43 points by iuguy 16y ago

preek 16y ago
My current employer's original wording: "We strongly feel that education is to be performed by every employee himself if he has an urge to learn." This quote is from our last personnel review meeting. Note: we are a Swiss company producing "solutions", not software - even every second employee is a programmer. I actually do have learned my lesson and am about to leave this company for good.
larsberg 16y ago
I wholeheartedly agree with the sentiment that startups should take more time to train their people. Back when I was doing a lot of hiring, I found that post-startup developers tended to have gotten broader (more technologies and spattering of business/customer skills) than college hires, but had neither better problem-solving skills nor had they improved their core development abilities (estimating, engineering at larger scope, etc.). That's as opposed to veterans from some of the shops with either training or mentoring programs like Google, where someone with even a couple years of experience has far superior fundamentals than a new college grad. Though I hate to reference him, I think it's related to the Gladwell distinction between just hacking up code and dedicated practice with the goal of learning and improvement.
gthank 16y ago
Does anyone know of startups that put this advice into practice?
dkarl 16y ago
Management training, maybe. Why you shouldn't train your technical startup workers: 1. They will learn on their own. 2. They will train each other. 3. They will learn by training each other. 4. They will often have to learn skills for which no training is available. Maybe I've been lucky, but my coworkers have always been extremely generous with their time, and I've tried to be the same way. These days there's also a huge amount of information on the internet: tutorials, technical presentations, and so on. Anything that's common enough to have in-person training available, there's a multitude of articles in addition to the official documentation. If there's professional training available but a lack of free or reasonably priced documentation, then it's a scam anyway and you might as well save your time and just give all your money to the nearest consultant.
- eru 16y ago
  Aren't your four bullet points arguments in favour of training? Just not in favour of hiring a dedicated in-person trainer. But setting up a system to disperse knowledge and allocate time for helping each other out seems useful.
  - dkarl 16y ago
    Management doesn't call it "training" unless it's organized and restricted in some way. One developer going to another and saying, "Hey, I need help with this," and the two of them going through it with a terminal or a whiteboard is not "training" unless it done on management's schedule or recorded in some training web site. From management's point of view, if they can't track and report it, it doesn't exist. So if you want informal training run by developers, you tell management you don't need any training at all.
    - eru 16y ago
      I am glad my workplace is a bit less pathological.
      - dkarl 16y ago
        You did say "setting up a system to disperse knowledge and allocate time." That's management talk. Nobody should need to get time "allocated" so he can use the "system" to disperse knowledge. There's your pathology right there: the idea that developers can't or shouldn't manage their own time, not to mention the idea that developers don't know how to teach each other or write documentation without management setting up a system to help them.
        eru 16y ago
        Oh, my talk may sound strange because English is not my first language.
neworbit 16y ago
...and we don't because we are (too) focused on the sprint, not the marathon. This is solid advice. But you need to start by training the people who need to train others. If you have a bunch of great individual contributor engineers who don't know how to manage, instruct, and the like - you will spend a lot of time reinventing the wheel. But once you crack that and can build a broad knowledge base for instruction and a corporate culture that supports it, you can scale. And that is why startup entrepreneurs should like this concept. Well, that and superior employee morale/retention.
kin 16y ago
In terms of new hires, yes, they should absolutely be trained. Getting hired at a new company, I am always lost. There's so many things that you don't know about the existing code base. Thus, the solution of FB's two week boot-camp to get employees up to speed is IMO what every company should do. But for start-ups my experience has been that everyone is learning and teaching one another and developing simultaneously. The whole process of being in a start-up is itself training.
lelele 16y ago
If you don't train your employees, they will learn on their own and they will make mistakes... at your expense.

43 points by iuguy 16y ago

preek 16y ago

My current employer's original wording: "We strongly feel that education is to be performed by every employee himself if he has an urge to learn." This quote is from our last personnel review meeting. Note: we are a Swiss company producing "solutions", not software - even every second employee is a programmer. I actually do have learned my lesson and am about to leave this company for good.

larsberg 16y ago

I wholeheartedly agree with the sentiment that startups should take more time to train their people. Back when I was doing a lot of hiring, I found that post-startup developers tended to have gotten broader (more technologies and spattering of business/customer skills) than college hires, but had neither better problem-solving skills nor had they improved their core development abilities (estimating, engineering at larger scope, etc.). That's as opposed to veterans from some of the shops with either training or mentoring programs like Google, where someone with even a couple years of experience has far superior fundamentals than a new college grad. Though I hate to reference him, I think it's related to the Gladwell distinction between just hacking up code and dedicated practice with the goal of learning and improvement.

gthank 16y ago

Does anyone know of startups that put this advice into practice?

dkarl 16y ago

Management training, maybe. Why you shouldn't train your technical startup workers: 1. They will learn on their own. 2. They will train each other. 3. They will learn by training each other. 4. They will often have to learn skills for which no training is available. Maybe I've been lucky, but my coworkers have always been extremely generous with their time, and I've tried to be the same way. These days there's also a huge amount of information on the internet: tutorials, technical presentations, and so on. Anything that's common enough to have in-person training available, there's a multitude of articles in addition to the official documentation. If there's professional training available but a lack of free or reasonably priced documentation, then it's a scam anyway and you might as well save your time and just give all your money to the nearest consultant.

eru 16y ago
Aren't your four bullet points arguments in favour of training? Just not in favour of hiring a dedicated in-person trainer. But setting up a system to disperse knowledge and allocate time for helping each other out seems useful.
- dkarl 16y ago
  Management doesn't call it "training" unless it's organized and restricted in some way. One developer going to another and saying, "Hey, I need help with this," and the two of them going through it with a terminal or a whiteboard is not "training" unless it done on management's schedule or recorded in some training web site. From management's point of view, if they can't track and report it, it doesn't exist. So if you want informal training run by developers, you tell management you don't need any training at all.
  - eru 16y ago
    I am glad my workplace is a bit less pathological.
    - dkarl 16y ago
      You did say "setting up a system to disperse knowledge and allocate time." That's management talk. Nobody should need to get time "allocated" so he can use the "system" to disperse knowledge. There's your pathology right there: the idea that developers can't or shouldn't manage their own time, not to mention the idea that developers don't know how to teach each other or write documentation without management setting up a system to help them.
      - eru 16y ago
        Oh, my talk may sound strange because English is not my first language.

neworbit 16y ago

...and we don't because we are (too) focused on the sprint, not the marathon. This is solid advice. But you need to start by training the people who need to train others. If you have a bunch of great individual contributor engineers who don't know how to manage, instruct, and the like - you will spend a lot of time reinventing the wheel. But once you crack that and can build a broad knowledge base for instruction and a corporate culture that supports it, you can scale. And that is why startup entrepreneurs should like this concept. Well, that and superior employee morale/retention.

kin 16y ago

In terms of new hires, yes, they should absolutely be trained. Getting hired at a new company, I am always lost. There's so many things that you don't know about the existing code base. Thus, the solution of FB's two week boot-camp to get employees up to speed is IMO what every company should do. But for start-ups my experience has been that everyone is learning and teaching one another and developing simultaneously. The whole process of being in a start-up is itself training.

lelele 16y ago

If you don't train your employees, they will learn on their own and they will make mistakes... at your expense.