Challenge everything, don't take any information for granted, look for the core substance the author is trying to sell and build from that on. If you don't click you'll learn mechanically and wont help you in the long run.
Most trainings and courses rely on what i call the "triangle method". Where you get a really nice image that exposes a theory via visuals. That is because once you got the A-HA behind it, it's really easy to derive and to find alternative ways of sharing that idea (via visuals, rhymes, analogies etc). But to your audience, initially they'll just see a triangle, and will have to backtrack your steps to get finally to the A-HA!. Wouldn't it be easier if we had the core up front and then waltz together to the final triangle?
Think about it, if you were to explain the field you are an expert in to someone, could you do it? Do you need to re-study? Most likely not. Why not? Because you got the core A-HA from it, which makes it candy to pass on.
Core
I want to touch a couple of examples and concepts, see below:
- Agile/SCRUM
- Leadership training
- Design Patterns
- Good trainer, Bad trainer
- Recipe learning, real learning
- Complex domains
I've worked agile for a while now, and i've seen it work. Still, i've also seen it fail. By analysing the failure, i couldn't stop thinking: "well.. it failed because they didn't do that and that". I was always wondering, where is that point when you fail. I mean, in each situation it seemed obvious what went wrong when you backtrack it.. so why did it go wrong. Following the principles, surely you could fix it no?
The reason it went wrong, is because it was applied as a recipe and not as a principle. The agile methodology is quite simple: you adapt to your environment as you progress. If someone sais "well you are doing it wrong because you have too many meetings", by all means, don't have so many. Tweak what works for you.
There are some guidelines that were proven to work in some contexts, but don't take them literally. I've had teams that did two daily stand-ups, that skipped retrospectives that had little to no planning. And that is fine, the core value is to adapt and keep the value coming to the client. Of course each decision was justified in some way, so that you don't lose key values that those ceremonies added, instead you get the value by other means.
Example: two dailies allowed the progress to be accurately shared with the client, whilst keeping the day to day goal tracking off their scope. Point is, you adapt. You're agile. Why force a rule?
Here are some online criticism i've found (Dark Manifesto), and let's see why is that happening
We are uncovering better the only ways of developing
Does this smell like recipe approach? Who enforced a single way of developing? There are some guidelines, but you can write your own.
I won't dwell too much on this subject, the point is: if you learned via a recipe versus a core a-ha behind it, you're going to have a bad time.
To make this clear, an agile approach on a project may even state: "Agile is not for me in this project!" See the Cynefin Framework.
Leadership training
Our company has grown quite a lot. To keep up with the growth a new approach to leadership had to happen. One that could scale. So, we've received training on the matter. Ranging from emotional training to managing different types of people to bringing out the best in people to career paths and so on.
It all sounds excellent, however, it assumed the fact that the new methodology would be embraced equally by everyone. Now, before i go any further, i have to say that these trainings are reaching out to your core principles and values. How you tackle a tough situation how you react and how you express your views. So this was not like a technical training, but actually it changed the way we think. I am doing my best here to move away from the "brain wash" phrase, but bare with me.
There are two aspects i'd like to explain to you on this.
One aspect would be the challenge i had to make on the approach. Like, why should i change the way i think, and why to this particular implementation. There are several others out there. Why this one? It's more than learning C# over Java.
The other aspect was around the fact that we were given "tools" to apply this. These "tools" were presented in the form of "triangles" (yeah.. i know) and 4 quadrant diagrams, and graphs and so on. To enable us to easily access and implement the flow.
I have to say, i have a problem with "triangles". I've started this whole blog to try and share my "a-ha"s by moving as far away from them as possible. Nevertheless, these guys (the trainers) had a history behind them, so you have to admit that maybe, just maybe there is some truth behind it.
So i started research, on how other companies scale, and what are their means, and what is their framework, and specifically why is it ours different.
This is where i got my first A-HA. They all more or less say the same. Ok, so the approach we were given was not in terms of substance, but on how we chose to apply it. Think of it in terms of flavors. For example, every leadership approach out there states that "yes, there are different types of people", it's just that our approach chose to adopt a particular vocabulary versus another when describing them.
Ok. Got it. So the material is good. It's been proven out there. It helps me be a better man, regardless of what i do. So sure, i have the buy-in on them now.
Then i began reading a bit more into the approach, on the best way to pass feedback, good and bad. On how to help grow each person whilst helping the company. How to actually build that win-win relationship.
Once i got that. Boy did the "triangle" made sense.
On the flip side, i attended another training, held by a different company, which was not so good. To give you a better contrast on why not i'll state my concern:
The training was around feedback, specifically the bad type. A long "triangle" based presentation happened, at the end of which we were given cards, which stated "steps" on how to give feedback. (you can imagine the excitement i had when i saw them... )
So i challenged the trainer. "I am a line manager for 5 years now, and from what i know, i gave my feedback pretty good. Can i try without looking at the card, to pass the feedback (it was an excercise we had to do)? And then we can compare"
Which i did. The feedback came as "your approach sounds good also, can you now try the recpie?". For the sake of the excercise i did. It was something similar to trying to get a mechanical engineer out of his shop on the double, and set him up to hold a speech to a large audience and win votes. Horrific, clumsy, it had that certain feel of ... fake.
The problem was, i was following their advice: "use the card!" (aka don't think/feel). So i applied a recipe, which i didn't believe in, a blind approach to a real problem. It was not the best training i attended.
I do accept that it may have some science behind those steps written on the card. But as long as you don't share your insight, your a-ha, it will NEVER work.
If i were to give that training, i would have went for "what is it, that I use, when providing feedback, to maximize the results". Why am i doing certain things over others, not how, but why. Once that clicked, the card would have been a redundant material.
Design patterns
I promised myself to keep this side of the blog non technical, so i'll do my best to abstract away the details.Of this story.
There's a certain way to structure your code, to have certain benefits. Whenever i hold an interview, i never ask: "can you explain the repository pattern", instead i leave the candidate to walk me through a few design patterns he chooses. I need to understand not how the pattern works, but how did he understand it. Because from his baseline understanding, he will derive his explanation. If it's a really good a-ha of a pattern, his explanation will be brief, and will be able to answer any question, adjustments, disadvantages, examples etc. If the understanding is around the code, he will walk me through the code syntax (not so good). If his understanding is of "the reason why i'd use this", well, from here we'll discuss the why and when not the how.
When you learn a design pattern, don't look at the code. Look at the principle, what are you really doing with it. Think of a real scenario where it would help. Then think (or do) a flow through it. Then i expect the UML will make more sense. From there, the code should be obvious, and you can have a reference code in terms of best practices, rather than the core principles.
Good trainer, Bad trainer
I'm sure you've all attended trainigns/presentations that left you amazed and with a nice lesson. On the flip side, i'm also sure you've also attended boring trainings/presentations/articles (hopefully not mine :D). What is it that made one session better than the other?
My epiphany came when i analysed the way the session was "sold". The content of a course usually follows some best practices (intro, examples, workshops etc), so i doubt it's the material to blame. However, the way this material is sold, what key elements are emphasized makes a difference.
Like in my previous example, in one training i was given the end result. The recipe i had to work from, as opposed to understanding the principles.
Same goes when applying to a job, and preparing your self for it. You can read the material, see the code etc. Or, you can try to understand the concepts. Specifically on the design patterns, why is this an interview question in the first place? What are they after? Start from there. Then you can see that in certain domains, certain patterns help (because of reasons you'll have to understand on your own - aka find their a-ha). And then you'll have a better view.
Recepie learning, real learning
The trainer and the trainee chose how they'll teach/learn. You can recipe learn, and in some cases this works excellent (environments which have to follow complex protocols and routines that guarantee a certain outcomes - building a computer from parts) but when the work requires you to be "creative", that's when a recipe learning will fail you.
For example, in the software industry we refer at times as "over engineering" to some implementations. When people follow a certain complex pattern, which covers a lot of areas, but is not needed in the context. The approach most probably cost more, and was applied blindly. Instead of building what's needed for a client. This is where "you have to think". And your experience list of "a-ha"s will make the difference.
I personally try to move away as possible from any recipe. I challenge everything when it's presented to me. Yes, but why? Until i understand the concept and reason behind, i will always challenge it. (Oh and trust me, at times this lead to tough conversations). However, once i have the buy-in on a certain design approach, or value shared etc. it's no longer a service providing activity, but more of a team effort to achieve the common goal.
Complex domains
So, the question still remains: but how do you tackle complex domains? Where you can't just really go: "Ok, so if i want to study C#, what's the underlying A-HA i need to kick off from?".
In complex domains, i see it as a divide et impera approach. Any piece of software (or any other complex context for that matter) is usually composed of several bits. Each bit, having it's own sub bits and so on (if it were easy, everyone would be doing it and it would be cheap). So you'll need to break it down to a level you have an understanding of the "a-ha" that will allow you to derive the context. And move to another area.
This is why, no matter how smart you are, experience is sometimes ireplaceable.
There are several ways of approaching a complex domain.
Bottom up: as in, take small key concepts and break them down until you got their "a-ha", then move to others, up until you get the "component"'s bigger picture and so on.
Or, there's the top down, where you get the final complex domain, and create a map of what you need to understand to be able t deliver. Not every bit has to be understood end-to-end. For example when i'm building a website, i don't really need to understand how my data layer's internal mechanics manages the information. I just know, to a certain level, that it provides me with certain features and certain limitations, has it's strong points and it's weak points.
I personally prefer this approach especially when dealing with large projects.
So if you were to build ebay from scratch, what would you need?
- marketing knowledge
- coding knowledge
- etc.
And dig deeper.
But if you were to pass on a project (of any nature) you've worked on, a complex project, how would you go about to pass it on? I'm 100% sure you own it, and you can talk about it for days, but to actually make it stick, you'll have to focus on the key "a-ha"s to shorten the time needed for the trainee to get up to speed.
The A-HA of this post
Each lesson/article/blog/presentation is based on some previous research. The form it's displayed is a concentration of information to make it "easier to remember" not necessarily "easier to understand". To understand a concept you need to understand the core, the a-ha of it. Once you have that, the course materials will be just confirming and providing analogies for the concept.
When learning, look for the underlying a-ha. When passing it on, focus on the a-has and work your way to the "triangle" not vice-versa.
