Seven Transformational Training Assumptions

In the appendix of his book “Why Employees Are Always a Bad Idea”, Chuck Blakeman lays out his philosophy around training with 7 fundamental assumptions. Since we are all about training, coaching and mentoring here at SAS Workshops, I thought I would elaborate on his 7 assumptions and how I think they apply to training and software engineering.

I agree with Chuck’s overarching assumption that the point of training is not to cram knowledge into your head, but to cause change for the better in your life. I somewhat disagree with the choice of his words since learning is one of our source commitments. A lot depends on your understanding of the word learning:

1. This first point is very much related to the overarching assumption. I also quite like the idea of focusing on desired outcomes rather than exactly how we get there.
2. I think you can very much relate this point to agile software methodology. Knowledge in a vacuum without application is kind of useless. The real test of what we know is how it applies in the real world. The key in agile is iterative interaction. We do something, give it to the customer, see how it works and use that knowledge to guide our next set of actions. We can apply this idea not just to writing software, but to life in general.
3. I could rephrase this as “The chaos in our code is a reflection of the chaos in our heads”. If we want to change our code, we have to first start with changing the way we think about writing code and the process with which we approach it. Interpreting his comment about consultants and applying it to software, it’s not about fixing the code as much as it is about fixing the thinking and the process that led to the code. The code is just a symptom, not the problem.
4. What really sticks out to me in this the word reactive. I feel like so many software engineers are just running around putting out fires. Yes if your house is on fire, you should put it out. But if it catches fire multiple times per day, it would be wiser to invest in fire prevention than simply buying more buckets.
5. I have become a huge fan of simple lately. Do the simplest thing that works and only add complexity when you have to. Designing some overly complicated architecture certainly feels good, but would a simpler solution have moved the needle just as much with less effort?
6. I could summarize this as “talk is cheap”. It’s easy to talk about how things should be. It’s much harder to start taking steps in that direction. If it seems too hard, start smaller. There’s always something manageable that you can do to start you moving in the right direction.
7. To Chuck’s last point, the first item is about being decisive. Stop worrying about getting it wrong and make a decision. The last 2 points are related to accountability. Use your social structure to hold yourself accountable. Pick a date and broadcast it. It’ll give you some pressure and motivation to make sure that it actually gets done.

Applying this in other areas

Chuck’s list inspired me to write a similar document about our assumptions here at SAS about Coding. Be sure to check out our list of assumptions and let us know what you think in the comments.