Change is hard. It’s difficult. It sucks!
Well, it’s not really that hard. It’s hard because of how we deal with the change.
We hate change. We detest it. We resist it. We procrastinate. We put it off. We do whatever we can to avoid it. We make a herculean effort to avoid the potentially small effort required to make the change.
That is how we are hardwired. If our current state has some sort of equilibrium, a sense of sanity and acceptance of where we are, we would resist change. Even a change that is for better.
It is not because we do not like to make things better. We all like to be richer, happier and more satisfied.
It’s the process of change that we hate.
The more I learn about child development, the more fascinated I get at the similarity of the fundamentals between adult professional growth and child development.
Consider the following advice from Baby Center on helping your child develop fast:
It’s important not to frustrate your child with toys and activities that are way beyond his abilities, but a little struggling goes a long way toward learning new skills.
When an activity doesn’t come easily to your baby, he has to figure out a new way to accomplish the task. That type of problem solving is the stuff better brains are made of. If he’s attempting to open a box, for example, resist the urge to do it for him. Let him try first. If he continues to struggle, show him how it’s done, but then give him back a closed box so he can try again on his own.
Setting a goal or target, which is not unrealistic but certainly a stretch, and letting the child figure out how to get there, is the primary premise of learning. I wrote an earlier blog post about the Creative Stretch as well.
This child development model is similar to how the knowledge professionals should be groomed, matured and trained. Give a challenging goal and let them figure it out themselves.
If you had read my three-part series on Getting Things Done (GTD) and my implementation of it, you would know that I am a GTDer.
David Allen describes the following three stages to become a GTDer:
1. Understanding – You understand the distinct differences in the five phases of mastering workflow. You understand a project versus a next action. You know how to transform what you’ve collected by asking the key processing questions, clarifying what something is, and what you want to do about it.
2. Implementation – You have installed at least the basic gear to support a GTD system, including ubiquitous collection tools, functioning reference systems for your non-actionable information, and seamless buckets with “clean edges” for tracking your projects and next actions.
3. Behavior Change – The five phases of mastering workflow are second nature to you. You have changed the way you think and work and are achieving stress-free productivity on a regular basis. When you “fall off” you know what to do to get “back on.”
The first two stages are relatively simple. The third one is the most difficult.
On August 23rd, 1973 two machine-gun carrying criminals entered a bank in Stockholm, Sweden. Blasting their guns, one prison escapee named Jan-Erik Olsson announced to the terrified bank employees “The party has just begun!” The two bank robbers held four hostages, three women and one man, for the next 131 hours. The hostages were strapped with dynamite and held in a bank vault until finally rescued on August 28th.
After their rescue, the hostages exhibited a shocking attitude considering they were threatened, abused, and feared for their lives for over five days. In their media interviews, it was clear that they supported their captors and actually feared law enforcement personnel who came to their rescue. The hostages had begun to feel the captors were actually protecting them from the police. One woman later became engaged to one of the criminals and another developed a legal defense fund to aid in their criminal defense fees. Clearly, the hostages had “bonded” emotionally with their captors.
— Dr Joseph Carver, “Love and Stockholm Syndrome: The Mystery of Loving an Abuser”
This emotional attachment and protective behavior of an abused or captive person towards his captor, abuser or tormentor is known as “Stockholm Syndrome” and is coined after the 1973 Stockholm robbery incident. Though seemingly illogical and unnatural, this syndrome is common among hostages and those who are victims of abuse in a relationship. They exhibit behaviors that are protective and empathetic to those causing harm to them and ensuring to maintain the situation where they keep getting abused.
Thanks to Baby Center, I keep track of development of my kids. In doing so, something that always interests me are they reaching a Cognitive Milestone – a specific mental development event where the kid grasps a key reality or concept. An example is Object Permanence, where the infant starts understanding that things exist even if they are not observable. That is the reason he looks for you when you are not around. That is why he cries when you leave the room.
One’s professional growth should see some professional cognitive milestones as well. These are the indicators of growing up. They are the Aha or Eureka moments. Missing such milestones leads one to conclude that wisdom and experience may not be necessarily related.
One such professional milestone is when one fathoms the difference between networking and building relationships – terms most often used interchangeably. Its reaching the understanding that building and maintaining solid relationships are critical to one’s professional growth – simply being connected to others is not enough. There have been studies that have proved that the best and most effective knowledge workers have the strongest relationships and derive great learning and value from them.
If you have been following me even casually, you would know of my obsession with understanding and applying models. Accurate modeling helps in efficient understanding of the situation, stops us from reinventing the wheel, reuse solutions that have worked before and ensures that we do not leave out anything in our analysis.
Mathematics has not been my forte but that will not prevent me from foraying into it.
Let’s start with a Normal (Bell) distribution – a model that explains many common phenomenon. For example, distribution of marks in a typical university course and distribution of heights, weights or IQs of people in a community. It helps in finding the mean (most commonly occurring value), variance and standard deviation of other data around it. We can extract useful results and make accurate predictions.
The normal distribution focuses on the average – and how everything relates to the average or the most common. You can identify common clusters and predominant patterns. You can see the outliers at the fringes of the bell, but they are really just at the peripheries. They are not the focus of the model. There is a reason why it is called a ‘normal’ distribution.
A more interesting model is the Power Law. It is typically used to model a relationship where the frequency of occurrence of a quantity varies as a power of some attribute of that quantity. It’s a skewed relationship where for a small set of values, the frequency of occurrence of the quantity is disproportionately different from that of others. A good example is the distribution of wealth in a society. There is a certain number of people – probably less than 2% of the population – who are disproportionately wealthier than the rest. The rest are relatively of similar wealth relative to that elite set. The distribution looks like this:
I try not to get very techie in my posts, keeping my Computer Science background in the hood. The intent is to talk about management issues that transcend a specific domain.
But sometimes the temptation to get out of the hood gets … well – too tempting. Specially, when you can use a good analogy to explain something important. For example, how can the compiler tool help us model where we go wrong in managing people.
A compiler is a key ingredient of the life of a software developer. It translates the code that software programmers write into a language that the computer understands. When you see a programmer furiously typing away on his screen telling you he is writing code (to make the world a better place), in reality what he is writing is really for himself, his team and manager only. He is writing down what he thinks the software should do in a prescribed format and structure – it’s just standard English with a very strict grammar. However, the computer that needs to make that software available to the world, lives in its own complex world with its own language and rules. There is a need to translate what the programmer writes into a language that the computer understands. That is what a compiler does. When asked by the programmer, it takes all the fancy writings by the programmer and creates the instructions that the computer can work with. It’s like hiring a language interpreter when you visit the Amazon tribes. The fancy English you speak is unfathomable to the half-clad and crocodile hunting tribesman. The language interpreter acts like a compiler, taking what you say and other data like your facial expressions and body language, and translates into what the tribesman can understand. Hopefully, you and the tribesman can eat the crocodile together rather than they together having you for dinner.
Well, the idea is not to teach you about compilers but why it is relevant to our topic – why smart people fail miserably when they move from a technical role to one involving dealing with people.
Remember the good old college days when doing more was the norm. I am not talking about just more work – I am talking about doing more number of things. Half a dozen courses in a semester, multiple projects, assignments, sororities, fraternities, science club, that extra research work, volunteering for the local school – all this in addition to working part-time jobs to make ends meet. At any point of time, there were a dozen things that you had on your mind.
And it made sense. There was so much to learn and do. The only possible way was to do more. Some of it was mandated for you (by the college rules), the other a result of your passion and eagerness to learn. You wanted to get your hands in many pies. You liked to brag about all the stuff that you were juggling and doing well.
The same continued as you started your first job (even worse if you started up your own shop). Although work was more streamlined, specially if you joined a larger organization, but still as a newbie you wanted to do tidbits of everything from doing your work to helping others to volunteering to peeking to see how others do their jobs. Doing so much – and so diverse of it – made you feel cool. Your learning was on fast track.
And still it all made sense. After all, life still has a heap to offer and you just did not know enough. The only way to fill that gap was to do lots of things.
This do more approach worked well – until it stopped working anymore!
It’s late Friday afternoon. You are sitting in your office, exhausted and frustrated. The week could not have been worse. The project is a mess, the team is in disarray and the VP is breathing down your neck. You have fought off about a dozen fires since morning. You almost had a fist-fight with that marketing ‘dude’. You are not even thinking about the upcoming conversation with the VP. The weekend is ruined. The best you can do to soothe yourself is by believing that its just one of those days (though you think there have been too many of them lately).
There was a knock at the door.
It’s Neville (hint: inspiration from Harry Potter series).
Gosh, no. With Neville, you know its trouble. The expressions on his face do not suggest otherwise.
“Boss, we have a problem”.
“I am listening”.
“I have been trying to get this fixed by myself for past 3 days, hoping it will go away. I fear that we have hit a hard rock. Our credit card processing system for the upcoming launch is completely broken. We do not have a solution.”
So only when you thought your day could not get worse, Neville proved you wrong.
What would you do?
Earlier I argued why GTD is valuable for knowledge workers and what my GTD system is. Here is how I do my Weekly Review – a critical piece of the GTD system.
All processes in life run forward. Good processes also have intermediary checkpoints where progress is analyzed and adjustments are made. (e.g. A Scrum project team does retrospectives at the end of every work iteration – where the good, the bad and the potential pitfalls ahead are reviewed and course corrected).
Weekly Review is just that. It is an explicit weekly checkpoint in our GTD life where we deliberately stop doing the regular stuff, rise up from the life’s battlefield, take a stock of all the stuff around us, analyze the previous week and look ahead the next. We adjust, tweak and re-prioritize and take away or add stuff in our lives. It’s an ‘inspect and adapt’ activity – and is immensely powerful.
As important as the review, is the fact that it is weekly. A week is the optimal work and planning unit. Give someone two weeks for a task and it will be most likely addressed in the second week. Hence, most planning and reporting is done on a weekly basis.
My Weekly Reviews are on Friday afternoons. It’s scheduled for 30 minutes on my calendar. Friday is a good time with work traffic slowing down and I have better visibility into the weekend and next week.