Paradigm Shift – a significant forcing function
Here’s how I see it.
a Paradigm Shift can be applied in two general ways:
- From Origin: pause and remove everything you thought you knew, your biases and preconceived notions, your initial thoughts – start from a blank slate with the minimum fundamental constraints & requirements and go from there.
- By Goal: multiply your goal by 10x.
A Paradigm Shift is an extremely useful and powerful concept that can be applied in mindset, ways of working, product, problem, solution, teams…etc.
Extremely useful when stuck or in a loop of thinking. Or in desperate times.
Fundamentally, a Paradigm Shift is a significant change – drastically different from the norm. From this forcing function applied at a certain point, all upstream and downstream parts are forced to change to make it work.
As a result, at varying levels – some parts are forced to:
- improve
- output more
- shrivel up and die (redundant)
- consolidate
- shrink
- change function
- realign
E.g. if a farmer was told to grow the same amount of crops in 1/10 the time. That is a Paradigm Shift applied “By Goal” and would force many downstream processes to adapt. A farmer might find alternative crops, explore for a new magical fertiliser, borrow a fresh piece of land, pause the chicken farm that period…etc
I first learnt of Paradigm Shifts in one of my early general engineering classes – a course meant for all engineering disciplines. Our lab facilitator, who had plenty of industry experience, introduced it with the example of Henry Ford’s car production dilemma in the 1910s.
Essentially, many people wanted Ford’s cars, but supply was constrained from the fact it took a team 12 hours together to make a single car. Our lab facilitator then asked us for suggestions on what we might do and how we thought it might improved the production time. All our suggestions were marginal, and the resultant improvement was also marginal. He then said that Ford set the goal for 1 hour production time, and that forced them to develop the assembly line concept which reduced the time to ~1.5 hours. (I’m sure the story was simplified, but the message is there)
What stood out to me the most was the sheer audacity to aim 10x higher and not simply marginally. While there might be some falling short of a 10x higher goal, the outcome would still likely surpass any marginal goal from the fundamental change in target.
my context - 2 paradigm shifts in hackathons
There are two strong examples that come to mind for Paradigm Shifts in hackathons.
By Goal Paradigm Shift: pivot to win a major prize and 3 awards
https://devpost.com/software/grosseries
For SDHacks 2021, my team built Grosseries – An immersive VR experience to show everyday shoppers how their buying choices can drastically impact the world around them.
I made my team do a Paradigm Shift in a solution-pivot to build something never-seen in a hackathon before. Demanding a team of webdevs to build something in VR for the first-time.
This was my 2nd US hackathon, and it was the weekend after winning at TreeHacks. While TreeHacks was a full team of strangers, SDHacks was only mostly strangers. I managed to grab Marcus (my teammate from that TreeHacks team) to join me in forming a new team with 2 new strangers (Alvin and Rohan).
While Marcus and I only met and hacked at TreeHacks the weekend prior, it definitely makes a difference having even one person in the team that you know/knows you.
For this hackathon, I had formed my team around the preconceived idea we would build some webapp. Generally speaking, most hackathon projects are webapps – so I had thought to just get someone in frontend (Marcus), backend (Rohan/Alvin) with a touch of ML (me, Alvin). My mindset was that it would position us well to tackle whatever we wanted to build.
I was wrong.
During brainstorming, my idea for the hackathon’s environment track “build a receipt scanner that would estimate and visualise your carbon-footprint from your purchases” got the team’s consensus.
I setup a quick-call with one of the hackathon mentor for feedback, and pitched the idea to him for a sense-check. He wasn’t impressed. He said that this idea was a dime-a-dozen, and it has been done so many times in hackathons. It wasn’t novel at all.
I was kinda shaken. I realised that many of my ideas aren’t novel in the grand-scheme of things. Many in the past have followed similar trains of thoughts to reach similar ideas. I was trying to work on my thesis at the time, and it was similar to how a good project adds to the state-of-art.
But the self-reflection could wait. I had a team to lead.
I returned to the team with the feedback, as they were spinning up their webapp boilerplate and services. We paused and tried thinking of a new idea – on a focus to not be something done in a hackathon before.
I then recalled that at TreeHacks, the grand prize winning project was a VR game. I thought – what if we just do this idea, but in VR? So,
- if the original idea was: from user’s groceries purchases, scan receipts and show their carbon footprint via metrics and visualisations
- reduce it to its core concept: from user’s choices in groceries, convey their environmental impact
- imagine what would a VR version look like: in VR, the user goes grocery shopping, and whatever they choose will change the world around them to reflect the environmental impact.
I pitched this idea to the team, and we started laughing. Somehow, we rolled with it. Despite our absolutely zero VR development experience, we managed to build a working MVP and won our target track prize with 3 sponsor prizes.
I heard from a judge that we had actually scored the highest number of points overall (each project was judged by 3 judges to get an average score).
shout-out to my teammates
When I reflect, I’m extremely grateful that my teammates were the kind of people willing to shoot the shot and trust me. I was asking them to drop their initial expectations (of using their webdev skills) and do VR stuff outside their comfort zone. When I pulled the team together, we were aligned on the goal to aim for the 1st place prize in this hackathon – so it meant they had to trust that my suggested idea-pivot, if executed well, stood a chance to win. They had to trust themselves that they could build the MVP.
We basically broke the MVP into 4 components, tutorial’d our way into making our parts work, and integrated it at the end.
From Origin Paradigm Shift: what if we empower people to street-litter?
I think this was for HackHarvard, I was trying to form a team and spoke with a high-schooler. We were spit-balling ideas we had in mind on the problem of street-littering, when he shared his idea:
To solve the problem of street-littering, what if we not make it a problem in the first-place? How about “allowing anyone to litter, by having a bunch of small IoT robots that go around and collect trash”. Users could litter anywhere, and use their phone to drop a location marker to call a robot to come pick it up. We wouldn’t need any garbage bins!
I had such a good laugh 😂
An incredibly novel idea. Completely flip the original problem into being the norm. When I recovered from laughing, and ignored how he was suggesting we help bring the Earth we saw in the WALL-E movie – it made me pause.
Some questions that came to my mind:
- AHAHHAHAH
- The WALL-E movie was pretty good
- Okay, but seriously
- What about the rubbish residue? Could a bot pick that up?
- Could a lazy user be relied to properly call upon a bot?
- How efficient and reliable would the collection have to be?
- What would the robot look like?
- Okay, what about for a hackathon? Maybe claws on wheels?
- Are bins a bad solution?
- Maybe some sort of carrier system for the small bots would be useful?
- Oh I remembered seeing how buses were used to extend drone operating range somewhere
- …etc
The point is. I was so rigid in thinking about solutions to the problem, when a Paradigm Shift on the problem completely changed all the questions I was asking for the solution. It felt like my brain was suddenly allowed to think on a whole new set of angles.