How to Slow Time

Do you remember as a child when the summers seemed to last forever? When I think back to my elementary school days I can swear it seemed like the school year wouldn’t end. Why?

I believe it has to do with our age. As a 10 year old, one year is 10% of our life. It makes up for 10% of everything we know of the universe, or reality, and everything in our being. But as a 20 year old, that same year is only 5% of our life. Meaning it should feel like it goes by twice as fast, all else being equal. In an inverse example, as a 30 year old, a summer last approximately 3 months. But to a 10 year old, it would be the equivalent to a 9 month vacation! I think this is why kids find it easy to get lazy, thinking they have all the time in the world to finish their work and chores – all the time in the world to accomplish their goals. In a final, extreme example, taking a look at a 1 year old baby – that 1 year is the equivalent of a lifetime. Each day blowing his/her mind with realities and truths of the universe.

 

With this realization comes unease. It means the older we get (the less time we have left), the faster time will go by. The less youthful, energetic, and curious we become, the less time we have to accomplish our life purpose. So how can we break this down to find a solution?

Let’s start by understanding that the youth have much more opportunity for (A) Learning; (B) Experiences; and (C) Exploration. Each of these three things adds more dimension to their understanding of the universe. Each of these things adds a net new value to their being. There is Growth.

To apply this to our question, it would seem the solution is to always be learning new things, experiencing new things, and exploring new places. Always be growing.

If we’re not growing, we’re dying, both literally and metaphorically.

‘The Minimum Viable’ State of Mind

Quick and clumsy is always better than long and planned out. This was a core principle in Sun Tzu’s Art of War (also translated as Art of Movement). The belief being that just getting up and doing something is more advantageous than spending too much time trying to plan for every contingency. As long as a successful outcome is a clearly defined and benchmarked, use resources to accomplish just that. Nothing less, nothing more. Do the minimum viable amount for each iteration until you reach the ultimate end goal.

Let’s take a look at some of the reasons why. Many will seem highly correlated, and they are. I decided to divide them up to be easier to digest and think through.

1. ON BEING AGILE: Things change. The only constant in life is change. According to the 2nd Law of Thermodynamics, entropy will always exist in a system. This is also true in social networks, machines, or even government policies. We cannot make assumptions in our planning, because by the time we’re done planning and take the first step, the environment or requirements could have already changed. This is why we have to take smaller steps and re-align our target point as the target shifts. John Boyd, a US fighter pilot and military strategist credited for introducing Sun Tzu’s teachings into the US Airforce, would preach his OODA Loop framework. Observe, Orient, Decide, Act.

 

2. ON CREATING TIGHTER BENCHMARKS: By creating shorter and easier to reach benchmarks, we can figure out faster if our strategy is even viable or not. This saves a lot of time and resources. A company may have plans for a big new product or service. Before launching a full release across the globe, it would make more sense to roll out a launch with a first Minimum Viable Product  (MVP1), something with none of the bells and whistles, and a basic user interface, for example, to see if it is something customers even want.

In addition to the common new product example, this tactic can even save individuals from emotional stress. This “Light Ball Approach” introduced to me by Mark Reale from Gallop Labs, is ‘The Minimum Viable’ Trust framework. Rather than spending a lot of time thinking about whether someone (an employee, business partner, life partner, etc) is trustworthy, or going ahead and, without planning, just trusting that person with something significant, use the MVT model. Throw that individual a light ball to see if they can catch it and throw it back. If they can do this, throw them a heavier ball and see if they can return it until the balls you are throwing are big and heavy. If they keep returning this ball to you, you keep building trust over time. You wouldn’t invite a stranger to a weekend getaway, that is a very heavy ball. Trust would have to be built slowly to avoid a potentially stressful situation.

 

3. ON MEASURING RESULTS: By just doing it, we are able to see results. They should be at least somewhat measurable. We may fail terribly, but at least we would know where we stand compared to our end goal. A Minimum Viable Product for our new business idea could be something as simple as a landing page with our product images, followed by a “buy now” button. We don’t need to have any inventory, or a delivery process, an office or even any employees. A $10 website, and a couple hundred dollars in targeted Google and Facebook ads would tell us if we have a product market fit. If we track 100 clicks we know there is potential, and perhaps we should go ahead with our MVP2 and buy some inventory (storing it in our garage and delivering it personally), until the next MVP3 can be chased (securing a warehouse to manage deliveries).

An upgrade to a previous #whiteboard #diagram. Build Measure Learn. #lean #agile

A post shared by Ahmad Iqbal (@ahmiq) on

 

4. ON FAILING FASTER: Related to the third point, failing faster means earning our bruises and scratches by practicing handstands on a bed or a mat before a trying on a concrete floor. “Failure” has been getting a lot of attention recently as a good thing, but it’s important to understand that it plays one role in a larger framework for success. Just failure alone won’t make us successful, it must be coupled with learning, iteration, persistence, and maybe a few dozen more virtues.

5. ON JUST DOING IT: The act of doing the thing you want to accomplish, and engaging in that activity provides a better “playtime” environment in which the mind can start to experience patterns. It is easier to analyze and experience a problem when more of your life force and energy is dedicated to it. Just using your mind is one thing, but when you get out of the building, walk, talk, engage with others and surround yourself with the issues there is more “energy” from that environment flowing through you. You will understand the possible solution better, and how to best get there.

We should do the Minimum Viable Activity needed to A) determine if our goals are worth pursuing, B) identify where we rank in our ability to accomplish these goals, and C) staying safe from hurting ourselves or our resources.

The Ninja Turtles: High Performing Scrum Team

When I was a kid I wanted to be a Ninja Turtle when I grew up. They were so cool! The four of them successfully overcame any obstacle that came their way. How were they able to do this? How did Splinter create such a Lean and high performing team?

Let’s start by deconstructing their roles and responsibilities.

Each turtle possesses a very specific character trait. These are not necessarily skill sets, but rather archetypes.

Leonardo is the prototypical Leader – he has a vision and takes full responsibility and accountability for the other turtles, often putting them first. His emotional intelligence is very high.

Raphael is a Warrior – he is hot headed, stubborn, but with that comes a strong will and ability to enforce the rules. He is a disciplinarian.

Michelangelo is the Lover – he is amicable, and relate-able and can defuse a stressful situation. He makes friends quickly.

Donatello is the Wizard – he has the mind for problem solving driven by his boundless curiosity for nature and technology. He has a high degree of technical ability.

It’s interesting to note the similarities between the turtles and an effective Scrum Team. Master Splinter being the Product Owner (taking the ultimate responsibility of the team and prioritizing exercises and missions to achieve), Leonardo being the Scrum Master (the servant leader who must keep the team on track to execute on their commitment), and the rest of the turtles acting as the Delivery Team. They are self-organizing and cross-functional, and between them possess the wide range of skills they need to get the job done.

But most importantly they share one significant trait. Their willingness to learn. To overcome some large overarching obstacle (like Shredder) they each have mini obstacles of their own which they haven’t encountered before. The learning is inherent to their growth and abilities as a team. It’s almost like they crave to reach the teetering edge of failure so they can make a ground-breaking realization; then immediately integrate into their delivery plan. Whether hell or high-water, the mission will be delivered. And most importantly they are able to incorporate the learnings in real-time.

 

Minimum Viable Time Travel

The idea of having a time machine has lingered in our imaginations for a long time. But we also know it will be pretty impossible to go backwards or forward in time from the technical perspective. Not only do many mathematicians and renowned physicists say it’s impossible, but even thinking about the implications blows our minds so much we probably can’t even understand how one would get started on solving this problem.

Surely, we understand a time machine isn’t as simple of a technical problem, as lets say a federal government health care website (in that the engineering solutions are known), it could still be “hacked” in some crude form. And by “Hack” I mean a crudely and quickly putting together system that could deliver the objective.

So maybe a hack exists. Just mental time travel. Rather than space-time travel.

Some possible reasons for time travel:

1. To make smarter decisions (give myself advice)

2. Help others

3. Save time

4. Nostalgia (re-live the glory days)

Time travel seems to be thought of a physical journey, but what if it was purely mental or emotional – I think it’s possible to meet these outcomes without having to deal with 3 dimensional time travel.

I think the personal diary, or a time-capsule, blog, or annotations like the ones from Genius.com, fits this kind of framework.

By keeping a diary someone can revisit the past to learn from failure or success. The past can also provide the previous perspective they may have lost over the years (make smarter decisions/give myself advice).

Annotations are the other way, where they help the next person “forward through history” since your experience added additional information to the literature they were reading (saving them time from having to research the item themselves and potentially make a mistake). This also helps other people.

By leveraging technology and good note taking, I think we can all experience some benefits of time travel.

 

Sara: Hacking a Hackathon

Numbers_slide.001

www.saratells.info

Sara was a project a few friends and I decided to hack on for a weekend in September (Haani, Sumit, Zeeshan and myself). The feedback was great and we learned a lot. We took first place at the hackathon in Toronto (out of 25 teams), and then 3rd place at the Global Judging at MIT (out of several hundred). Here are four tips we discovered for “hacking the hackathon.”


1) Try to solve a Really Big Problem

The bigger the problem, the more likely you will have the attention of the judges and audience. With Sara, we were trying to solve the problem of internet access for five billion people. Identifying a big problem is easier said than done, but it’s important to focus on the steps to take to get there:  Pivots. Which is the 2nd tip…

2) Pivot

Pivots turn into steps. Hacakthons don’t usually last longer than 2-3 days so these have to be made extremely fast. Before landing on the idea of Sara we were brainstorming “Kasaan,” which means farmer in Urdu. Our idea was to build a simple Android app that would give real-time local commodity and produce prices to local farmers so they would know the true price of their goods. We read about many horror stories of farmers being ripped off by brokers and middlemen who benefited from asymmetric information. However good of an idea we thought we had, a quick Google search into the smartphone penetration in the sub-continent showed abysmal figures. Not only that but we discovered even those with smartphones did not have access to data connection. From there we pivoted to providing pricing data via SMS – which subsequently got us to thinking “why not just add a bunch of integrations to other search engines and web directories?” This is how we pivoted our way onto a “bigger problem.”

3) Try to go last if you can

This is an odd one. We did not do this intentionally, rather this was an accidental discovery. When you have so many teams competing (and usually hackathons have a specific cause or purpose) there could be an overlap of your idea with other teams. If the problem is a big one, your solution may umbrella other problems being pursued by other teams. We found there were several teams that decided to leverage the SMS medium to broadcast or distribute relevant information to rural users. This only validating our value proposition. Not only that but we were also able to position Sara as platform for other 3rd party search engines and directories to integrate with. We believe being one of the last teams to pitch made our service more top of mind than the others.

Most importantly, 3) Hustle to be memorable

We learned the underlying objective of any qualitative competition is to be memorable. With competitions like sports games or races, there is a definitive qualitative measure of success; but with a competition on who has the best idea, it’s a completely different game. Our strategy from the get go was to be memorable. We knew we had to stand out because judging can be influenced by so many tiny foreseeable forces. The tactic we used to stand out was getting application into the hands of everyone in the audience, including the judges, at the same time, during the pitch. This was probably just as time consuming as building the application itself. While our team of wizards were knee high in code during the weekend, I was making the rounds, introducing myself and offering product help to other teams in the space. I used this time to introduce (briefly) our idea and ask for their phone numbers in order for them to help us test and better our service (this was the original sentiment). Getting the phone numbers of the judges was the most important, but also harder. A few weird looks from the staff and volunteers shouldn’t deter you; the judges were happy to help. Once we had all the phone numbers, Sumit programmed a quick script which would blast a greeting from Sara to everyone on the list, encouraging them to ask her any question. The timing of this blast was of critical importance – we did it right at the end of our pitch, applying the proverb: Strike While the Iron is Hot.