"I don't like Idlis" - Titli
"But why? They are good. Try with Sambar. They will taste good" - Rajesh
"No. It is yuckyy." - Titli
"Why?" - Rajesh
There are narratives in our head.
Idli is good. It is healthy. It is easy to make.
There are narratives in their head.
Idli is yuck.
There are more narratives in our head.
This place is awesome to work.
The product is useful.
Writing code in a certain way is important.
It does not matter what our narrative is.
You cannot alter the other's narrative by asking
The decisions of
Where to work?
What product to buy?
How to write code?
are based on their narratives.
They are as valid as yours.
Make your narrative strong.
So strong that they feel that it is their narrative.
When we want to present what we are working on -
We typically present a list.
I am working on
Painting the car
Organizing the dashboard
Cleaning the boot
Changing the oil.
We do this is many places.
When asked - Why is your product better? - Out comes, a feature list.
When asked - What is the benefit of a process? - Out comes, a list of benefits.
When asked - How are you solving a problem? - Out comes, a list of items.
When asked - What does your NGO do? - Out comes, a list of activities.
The problem with lists are -
* They are hard to remember
* They are unexciting
* Hard to build on
* Very boring
It does not help that "To do" apps focus on lists.
It does not help that finally we have a bunch of activities to do.
Instead try to build and tell a story.
Stories excite everyone.
Stories are easy to present.
Stories are easy to remember.
"I will be driving my car on a cool trip - Visit places mentioned in this historical novel. So getting my car ready for it."
We have been tuned (evolution) to relate to stories.
"My very educated mother just served us nine pizzas" (or some variation if it).
So when someone asks
"What do .."?
Try starting with
"Once upon a time .."
"Should I put 4 cups rice and 1 cup daal?" - Me
"No. Why do we need so much? We are only 4 people" - Renuka
"But we always use that measurement" - Me
"Come on. We need it for 2 days of Dosa and idlis" - Me
"Oh. I thought you were asking measurements for the Khichdi" - Renuka
"Oh ok" - Me
When we communicate - we make lots of assumptions.
We think what we ask is what the other hears.
We think what we intend is what the other intends.
It is easy to start with wrong assumptions.
It is simple to correct.
Verify your assumptions.
If you are not sure - Ask.
If you are sure - Ask.
If you are really sure - Ask.
A dear friend of mine used to have a saying about assumptions.
It goes something like,
"Assumption is the mother of all fuckups"
"But I guess this time - It is ok. You are not well and It is hard to manage her" - Rajesh
"No" - Renuka
It is easy to explain away the deviation from the principles during difficult circumstances.
"I will skip the code review this time because ..."
"I will respond to customer late because ..."
"I will push my agenda this time because ..."
"I will pay bribe to get this done this time because ..."
"I will test this later at this time because ..."
The "cause" may be genuine.
The deviation may be warranted.
Either you stand for a principle or you do not.
There is no "but this time".
It is OK to decide that you do not agree or stand for a principle.
It is NOT ok to have deviations once you decide to stand for it.
That leads to
above all - "Broken trust"
"Why do you go to work, why not mama"? Titli
"Some answer .."
"For a restaurant it is good if they turn tables fast in a evening" - Rajesh
"What is 'turning tables'" - Girish
"Why is it good?" - Girish
"Is it true for all restaurants?" - Girish
Here lies the answer for the "Creator's curse".
When a question is asked about a thing that we have created mostly we do NOT hear the question being asked.
We hear it as "blah blah? You have not considered it? I just found that gap. What the heck you were thinking?"
or some variation of it.
If you have an inherent curious nature - You will probe more.
You will ask questions to understand more.
You will try to understand.
But that is hard.
Our instinct plays it part esp. when we are presenting to audience.
It make us defensive.
So here is a simple trick.
Always have a note book and pen when you are presenting.
When someone asks a question - Write it down.
(This helps to increase your response time. It cuts your instinct to add unnecessary addition to the actual question being asked. It helps to get clarity about the question. )
If you are not able to note it down clearly ask only questions that help you to note it down well.
Repeat the noted question to the person who asked it.
Thank the person.
Follow up later (if that is possible else respond now).
I am going to call it "Child like curiosity". (for obvious reasons)
Either have it.
or fake it.
It is a perfect Anti- Dote.
A recent post about - 'how wrong our instincts can be!' triggered some thought process.
I always wondered -
If eating healthy food is good, why do we get attracted (most of us) to sugar and fatty foods?
If exercising is good, why we have to discipline ourselves to do it regularly?
If learning is good, why do we have heated arguments with others who have different point of views?
If evolution works the way we think it does then, given the above - Why is our gut/instinctual reaction wrong?
We should be enjoying eating healthy food.
We should be exercising for pleasure.
We would be naturally curious.
Then a realization stuck me.
Our current level of abundance (in terms of food), freedom ( in terms of time), interaction action (with others) are a very recent phenomenon. Probably the last 100 years have changed these so much that our instincts that developed over millennia is yet to adapt to it.
Instinct for eating foods high on sugar and fat developed when they were scarce and body wants to consume and hoard as much as possible.
Instinct of intense physical activity is primarily oriented towards getting food. it is primed to NOT perform other activities. You have to be physically fit and able to use your body to hunt else you go hungry.
Instinct of defense developed to survive "Death by curiosity" or "Dissidence".
Our instincts are highly developed and good.
Just that it is a like "Gladiator" surviving in the modern civilization.
They do not fit in with the existing environment.
We have to control our instincts and work to get it right in the new environment.
That is why,
It is hard.
This thoughts reminded me of Robot_AL-76_Goes_Astray - A fascinating (little) story of a lost robot who was designed for working in the moon but lands in rural Virginia. Check it out if you are a fan of Asimov in the "The Rest of the Robots"
"Have you considered this scenario while ... ?" - X
"Do you think that is how a person will think ...?" - Y
"This seems to be confusing when I click ...?" - Z
It is surprising how quick the inputs flow through from people who are looking at anything you built (UI/UX, Product, Code, Business plan, Startup idea ...) for the first time.
Our first reaction is
"I have spent hours thinking about it. I have a good reason why the thing I built is like this. Do you think I am stupid. Here is the explanation for ...."
We are cursed to be blind - Being the creator of the thing, we are very deeply aligned with what has been created. We become blind to its short comings.
A simple test:
When someone presents you the outcome of their work - count the number of gaps/challenges you see in the output, without thinking a lot.
Take any of your finished work - see if you can match or beat the above number in the same amount of time.
You will know if you are cursed.
There is a simple and effective way to workaround this (not sure if it can be avoided) - In the next post.
There seems to be another definition already for Creator's curse. But I could not come up with a better name for the phenomenon I described.
"Are you not bathing today?" - Renuka
I get irritated.
"Why are you not asking 'When are you not bathing today?'?" - I retort (with a raised voice).
"That's what I asked" - Renuka
When I hear the question, there is a narration in my head.
It is based on my background (combination of ethnic, cultural, beliefs).
I was brought up as an equivalent of a "TamBhram - Iyer".
Only "brushing teeth" was allowed without bathing.
Bathing is the first (may be 3rd if counted accurately) thing we do in a day.
So what I hear when the question is asked as
"Are you not bathing today?"
"It is way past bathing time. You have not shown any inclination to take bath and are performing activities that should not be performed without bathing. Are you going to continue with this?"
We think what we ask is what the other person hears.
Not necessarily true.
We all have a narration in our head that interprets what's being said.
What you ask is "Have you considered simplifying the options, this seems complex?". What the other hears is "You seemed to have come up with a complex option. Why can't you come up with a simple one?"
What you ask is "Do you need help to have clarity on what and how you are going to do things?". What the other hears is "Hey! I think things are not being planned well. I want to know what and how you are planning to do things."
* When asking - be sensitive to the narration in the other persons head. If it triggers behaviour you do not expect probably what you asked is not what he hears.
* When responding - clarify the story in your head. What you hear is not probably what the other person asked.
It will make work and personal life simple.
"Interface" is an interesting concept of Object Oriented Programming.
I am fascinated by the 2 (the ones that I like most) important tenets of an interface:
* Interface exposes the behaviour i.e. what is expected out of the function call if you pass the defined parameters? It does not expose the implementation. In Fact it is designed to abstract the implementation. It is a contract with the external world.
* Interface enforces the implementer to think through contract of the exposed functions and handle them well. It ensures that whoever implements it, need not reinvent the contract everytime. Removes the communication overhead that comes with change of contracts.
As Recruiterbox is growing and more people have started contributing at various levels, the 2 tenets are helping me to think about how I can work well with them.
* I am treating each function (engineering, ops, product, design, marketing, sales) as an interface. I know exactly what every function is expected to do - "Defined by outcomes". But I do not have to worry about how it is done (curiosity may still exist).
* Within each function, the team understands the promised outcome and designs ways of achieving the outcomes. There is a conscious evaluation of the contract and implementation that works well for that team's current strength. This is defined by the "Rituals" (I prefer this term over process - details in another post) followed by the function.
Reference : What is Interface? - http://stackoverflow.com/questions/3355408/explaining-interfaces-to-students
When I chose my specialization in undergrad (Engineering) - The following was my thought process:
"Mechanical engineering is an evolved subject. Everything has a reference book (strength of materials, ratios to be followed for design etc).
Computer science is still evolving. New languages come every 2 years - Java had just been out. How long you will have to keep learning new things?
So - Mechanical it is."
Life laughs with ironies.
Though relatively young, it is amazing to see the number of paradigms that are evolving in computing science.
One that has created profound influence is - The free and open source software.
Professionals (who are really accomplished) - write free code for others to use.
From small libraries to operating systems there are tons of free (with source) stuff available.
Newbies can learn from it.
Good ones can contribute to it.
Others can use it.
As a amateur in some fields - Food production, Earth based construction, Design - I find the lack of equivalent of "free open source content" are not present.
Does this reflect on the professionals?
or the profession?
"We should always heat the older packet before opening the new one" - Renuka
"Yes I agree. The way to do it is, by ensuring the oldest packet is in the front. We have to ensure that" - Me
"But why don't you check the dates before heating the milk? It is possible that we may forget to put it in the front"
"How can we forget if we agree that is what we will do? It is waste of time and mindspace (hmm Rbox effect), if I have to check it every time. It is a very simple rule to follow"
"But it can ..."
"No. I Guess then you are ..."
We DID agree on the intended outcome.
What we did NOT agree about was "How to get it?".
It happens a lot.
As long as we agree on the outcomes, leave the "How?" to the person who manages it.
Discussing 'how' leads to discussing unintended 'whats', 'whys' and 'hows'.
If you feel strongly about the "How?" then may be you should own it or talk about it later.
* We buy unpasteurized organic milk. It has a shelf life (in refrigerator) of 2 days. The supply can be erratic and so we maintain one day inventory. This milk has to be be heated (boiled) before consumption.
* Being the early riser, I put the milk packets in the refrigerator - Oldest in the front and the last in the back. When I heat the milk, I just pick up the front most packets. When Renuka heats the milk, she checks the dates :-).
I started finding faults with the thought he was expressing.
I pointed out things that may not work for it.
Next time - I will listen.
Next time - I will think.
Next time - I will build on your thoughts.
As I wind up my day - I think it will help me to reflect on "What I could have done better?".
I think I am going to goof up a lot and hence the "?" in the count.
When you talk to yourself, your partners, your peers, your customers:
What is it for? When someone hires your product, what are they hiring it to do?
Who (or what) are they trying to change by using the product? From what to what?
How will they know if it's working?
What does it remind them of? Are there parallels, similar products, things like this that have come before?
What's the difficult part?
How much of their time and focus are they spending on the difficult part?
What part that isn't under their control has to happen for this to work? (Do they need to be lucky?)
How much (time and money) is it going to take to find out if it is working for them?
What assets do they already own that they will be able to leverage?
What assets do they need to acquire?
After the use of the product, what new assets will they now own?
Successful teams are delighted to engage in a conversation about all of these questions. If you're hiding from them, it's time to find out why.
"You like the pasta I cook, because I make it with lots of love"
"No. I like the pasta you cook because - It tastes good" - Titli
A good outcome requires good Intent.
Good intent does not guarantee good outcome.
Sometime we substitute our intent for a lousy outcome
(I tried my best, It was an honest attempt, I spent hours trying to figure out, Given the circumstances/constraints this is what I could do).
We forget that outcome is what matters - esp. to others.
Be clear about the expected outcome.
Have good intent.
Ensure the outcome.
My daughter likes the pasta I cook, because it tastes good.
PS: This is the reason I think a lot of NGOs fail. They have great intent - outcome is a "?".
"Don't read the newspaper. I am playing with you" - Titli.
Very often we zone out.
The reasons are many.
and It is okay.
The right thing to do is tell the other person.
The wrong thing to do is pretending to be listening, when you are not.
It breaks trust.
May I have your attention, please.
Learning seems to be a process that requires two actors.
But - When a teacher is around, he is compelled to teach.
Whether the learner is learning or not.
Then the teacher tries to measure her success by testing.
Learning then becomes a process of preparing for test.
"Learning" is lost.
In reality learning just needs a learner.
The teacher is incidental.
All one can hope is build an environment that encourages learning.
Everything else is fluff.
PS: Thoughts summarized from assimilating various writings about sudbury valley school by Daniel Greenberg.