Working And Learning
In a recent post, my friend Tom Harris writes about the process of learning at work. As you might know, this is one of my favorite topics.
Tom describes something similar to a decision tree to help you come up with a plan regarding how you want to treat the process of learning and the process of fixing defects in your business. Yes, the two are related.
I will risk by saying that I believe that Tom was suggesting just that. However, his post leaves some room for a doubt.
I strongly believe that focusing only on fixing bugs is not cost-effective. Focusing only on classroom based training is also not cost-effective. In my opinion, Tom’s decision tree leaves too much room for choosing the “bad” options.
If you spend all your energy on identifying and fixing bugs without investing in long-term training, the same errors will just keep showing up. Similarly, if you spend all your energy on classroom-based training, which is by definition decoupled from the daily work your employees perform, they will find what they’ve learned in the classroom hard to adopt to their real needs and the real problems they face.
The fact is that most of what we do in our industry requires extensive experience and context-sensitive learning. Building this experience and this context-sensitive knowledge (which one can call “intuition”) depends on mentoring. Achieving true professionalism using only classroom-based training is not feasible. And of course, if you only look for bugs and don’t want to have anything to do with training whatsoever, you will never achieve professionalism.
This might seem extreme, but if you really want to do the right thing for your business, you have to improve the skills of your employees. You have to consider mentoring.
Of course, mentoring cannot stand by itself. Conventional training also has its place. And of course finding bugs and fixing them is important to the daily operation of your business. But without ongoing mentoring you will find it hard to improve. You will always be running in place.
Another important point is the connection between mentoring and fixing errors. Neither one can substitute for the other. On the contrary. They can, and should, be used in synergy to improve professionalism. When mentoring is based on real-world problems, for example by identifying and fixing errors with the mentor, the developer gains experience in a guided manner. At the same time, the product is being improved by the joint work of the developer and the mentor. And as a side effect, the next phase of development will contain fewer errors.
Tom’s decision tree is of course accurate. Theoretically, you have the option to choose between just fixing bugs, naively training your developers, or providing them with real and effective mentoring. However, if you want to succeed as a business, increase your productivity, and beat your competition, you really don’t have a choice. You must invest in your technical staff.
Investing in your technical staff means providing them with effective mentoring to turn them into software professionals.
June 30th, 2006 at 4:49 am
Hi Lidor,
Thanks for reading and writing.
It’s true that I left some room for doubt. People have doubts — I just wanted to encourage people to draw conclusions from their decisions. And if they don’t like what follows, they should change their decisions, probably in the directions you’re suggesting.
There may also be a question of revolution or evolution (and I’m not taking sides here). Someone who believes in evolution pointed out, for example, that a centralized training program, but with trainers and students both workers from the same company, could encourage people to build mentoring relationships, and team relationships, based on having gotten to know each other as student and trainer in a course.