Where should employee training/reinforcement of new skills and techniques fall into the project life cycle? Is anyone able to find any studies conducted about how the end product is affected resulted if training is done on the production code during development as opposed to conducted between projects on non-production code.

My team just finished a few releases of different product variations. We now have some lull before our cycle picks back up. Being the team lead, I gave the team members an assignment to re-write an application (one used to gauge prospective employees) using things they've learned since joining the team. Things expected to see was use of dependency injection, unit testable code, and use of the MVVM pattern (a C# WPF design pattern).

My supervisor found out and didn't think this was the right thing to do with this down time. He believes that employees should learn the above things on production code/products to be shipped and that any additional learning and such should be done on their own time.

I do see the business perspective, but we currently have a product that we are about to redo from scratch because we employed this way of thinking in the past. I don't think we should do this, as that produces code that is hard to maintain and is usually buggy.

Did I make the right call for this lull or is there something better to do with the time? I was unsure what to search for and any studies conducted would be greatly appreciated.

  • Far better question - retracted my VtC and upvoted.
    – MCW
    Commented Nov 3, 2016 at 13:33

3 Answers 3


In my view, formal training has no place whatsoever in a project life cycle. None. Projects are, by definition, discrete pieces of work having a finite time period and finite resources. No project dollars should be invested in formal learning of any project team members.

Informal learning occurs as a consequence of doing work. Training on the job of a newer team member is normal and project dollars will go towards that; however, work is still progressing during that time even when some rework needs to occur.

Other types of sanctioned project training would be for specific project type things that have to be transferred to the team. This is so the team will know how to operate within the project context but also to train something that cannot reasonably be found in the general resource pool.

Otherwise, the buyer of a project should not be on the hook to spend their money to train people who are only associated with his product for a specific period of time. That's 100% inappropriate.

My views on this subject are unpopular, I know.

  • 2
    Training is part of operations? US government agrees with you (during alternate administrations). Good catch. Devil's advocate - what if training is required to address a quality issue/technical debt?
    – MCW
    Commented Nov 3, 2016 at 14:57
  • 2
    Expanding on @MarkC.Wallace's point: Let's say I ran a C# shop, but I have an un-expected Fortran integration. The client knows that they didn't hire my folks for their Fortan skills, but still wants their problem solved. I can send someone on a training course for $X and then have them solve it, or hire a Fotran expert for $5X. I don't think we'd choose the second option merely on principal. Perhaps the division is between longterm-internal-investment vs solves-business-need? Formal training just happens to (mostly) fall on the left side.
    – Nathan
    Commented Nov 3, 2016 at 16:48
  • 1
    I agree with both of your comments. That's what I meant by my 3rd to last paragraph around project sanctioned training. If something unusual is occurring, then formal training would be not only appropriate but likely your only alternative in many cases. Commented Nov 3, 2016 at 19:05

While there might be a theoretical 'best practice', in reality it depends in large part on what your organization values. Even the decision to go ahead and assign a new project to the team rather than 'consulting'/'wasting the time of' your supervisor could be seen as a bad/good thing.

Has your supervisor been apprised of the costs of technical debts? If so, that's something that definitely needs to be done - not just for things like this, but for new development as well. If executives don't know the cost of technical debt, then they cannot make informed prioritization decisions regarding technical debt. If they do know the cost of technical debt, and they tell you to work on something else, then you should listen to them unless you have some cause to believe you understand what the priorities should be better than your superiors. In which case, you have bigger problems.


Training is a continuous process. Hence, an informal training takes place on every single aspect of process. In case of formal training one need to follow the company or project guidelines.

Or else the best way could be PMI/TSAT etc. to identify training need.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.