Self-Training

A while back, I implemented "self-training" for my team. So far, I think it has been a success.

This is a mandatory task for the team. “Mandatory” as in it counts towards your performance. “Task” as in you do it. “Team” as in the team.

Here are the rules:


  • Must do at least .5 hour per day

  • Can not roll it over until you do it all in one day (i.e. 5 hours on Friday)

  • You can use as many hours as you want towards a particular subject

  • Any topic that is related to what we do is fair game

  • If you want to buy a book or something, let me know. I will get it expensed.

  • I can ask you to change it, expand it, or focus it if it seems like it does not accomplish number 5 or if you are spending too many hours on it.


So, Why? What's the point?

  • To become more awesome

  • To save Vail time and money

  • To master your craft


I am sure that we all do some of this on our own. However, I wanted to structure it so that we will be accountable to one another for it. In other words, you can’t say you are learning something and not do it because one of us may ask you about it.

Some of the self-training subject matter will overlap with something you are assigned to do. For example, I don’t know much about implementing a central authentication systems. And, I want to implement it at Vail. I may self-train on it.

If that is the case, I would suggest approaching the self-training hour from an objective point of view.

“How does it work?” As opposed to, “How can I get it to work for Project xyz?”

It is a subtle difference and may not matter in practice. But, I don’t want to be biased in what we are learning towards some project timeline, or limitation.

In the end, it is all about being better. What we do is our craft. We should master it.


About this entry


1 comments:

  1. Jszilla August 1, 2008 at 8:59 AM

    This is a great idea and I intend to steal it from you and take all the credit.