Back in the 40s, TVs were giant, ugly behemoths. They were jammed with vacuum tubes, big bulky components, and were prone to overheating and failure.
Earl “madman” Muntz was an engineer and businessman who started repairing radios when he was 8 and built his first car radio when he was 14. As only someone with the nickname ‘madman‘ could do, when he worked in the TV business, he would walk around the factory floor, step in front of an unsuspecting engineer and yank components from TV sets until they stopped working. Then, he would put the last removed component back in and the set would often work, but with fewer components (thus cheaper) and often other benefits such as reduced heat.
Netflix not included.
This practice became known as muntzing, which while it sounds like some awful way of hazing people with a hosepipe, it was actually a deliciously simple exercise in efficiency and cost reduction. Rather unsurprisingly, this provides an interesting lesson we can apply outside of knackered, old TVs from the forties.
Simple but not Simpler
Muntz’ was fundamentally zoning in on simplicity as a way to accomplish efficiency.
He wasn’t the first. Around the same time period, Einstein, a man not especially unfamiliar with genius, said:
“Everything should be made as simple as possible, but not simpler.”
Einstein touches on the elegance in simplicity and not to be fooled by thinking simple minds create simple things. We see this every day with seemingly simple devices (e.g. the iPhone) that carefully conceal enormous amounts of complexity behind the scenes, both in terms of technology and workflow.
Somewhat smart fella.
For the work I do in building productive and engaging communities and organizations, this is nirvana. My ultimate goal is to build human systems that deliver solid, productive, and predictable results but are simple in their instrumentation and use. As you can imagine, there is often a lot of complexity that goes into doing this.
So, Muntz and Einstein give us a good recipe: focus on simplicity as a means to accomplish efficiency, and reduce the complexity as a means to become lean. Sounds great in theory, but how do we do this?
Harnessing Adversity to Build Efficiency
There are various reasons why things become inefficient: people get lazy and take shortcuts, complexity slows things down, too many layers of abstraction contribute to this complexity, people accept the new reality of inefficiency and don’t challenge it…the list goes on.
We see this everywhere in the products we build, the organizational methodologies we have in companies and communities, the systems we have to use to file our taxes or invoices, and elsewhere. Not seen this? Go to the DMV in America. You will get it in droves.
An effective way to create efficiency and optimization is when we have manageable adversity. That is, we face tough situations that are within our control, capability, and power to resolve and learn from.
Muhammed Ali said it best:
“I don’t count my situps, I only start counting when it starts hurting, when I feel pain, that’s when I start counting, cause that’s when it really counts.”
Our most difficult moments in life, when we can feel beaten down, tired, and lost, can be the most formidable times of personal growth, evolution, and development. If we therefore instill the right level of adversity into our work, complete with having the ability to resolve it (which is the key difference between adversity being a helpful thing or a discriminatory force), we develop efficiencies.
Putting This Into Practice
As such, there can be enormous value in deliberately injecting adversity into our work as a forcing function to get better results. In other words, sometimes the easiest path forward is not the best path if we want to increase our capability and creativity. Sometimes throwing a few obstacles people need to navigate can be a useful thing.
Here are five recommendations to consider.
1. Add intentional burdens
Baseball players would use two bats, drummers would put additional weights on their ankles, and powerlifters would lift additional weight beyond competition requirements all for the same reason: when you remove the additional burden, your performance improves.
Think about how you can instill an intentional restriction that will force you and your teammates to think creatively around how to solve the problem.
For example, an ex-colleague of mine at Canonical was once facing a very low-level bug in the Linux kernel, before the screen was powered up. As such he saw no error messages to indicate the issue. His solution? He wrote a kernel driver to flash the caps lock light in morse and used a sensor sat on the light to read in the morse to see the issue.
He faced a burden, and that burden generated a creative solution. In a similar way, Steve Jobs famously demanded Burrell Smith accomplish his vision of the first Macintosh with fewer hardware components than he had available. These burdens generated remarkable outcomes.
2. Require an ambitious metric
Create an ambitious metric that a solution is required to accomplish. It is incredible what people will do to accomplish a given metric, be it a score in a video game, a measurement on a device, or a target weight to get into a suit at a wedding (ahem!).
A good example here was the first XPRIZE (I used to work at XPRIZE a few years back). A $10million prize would be awarded to a team who built a reusable spacecraft that could go up into space and back, twice in two weeks.
Bags fly free.
This ambitious requirement to win the competition made teams think creatively across a wide range of engineering challenges to accomplish the goal. The result: the birth of commercial space travel development.
Think about how you place an ambitious requirement for the outcome of a particular project, and one that really helps the team to focus on accomplishing that goal in a creative, lean, and ambitious way.
3. Iterate and optimize
An approach I use throughout my work is to break work down into smaller pieces to (a) generate data we can use to assess the success or failure of a project, and (b) to use that data to iterate, improve, and test again.
This is one of the most fundamentally important approaches to evolving any kind of product or process: we can’t improve without information and iteration. As one consideration when iterating, always ask the question “how can we do more with less?”. Tiny improvements and efficiencies on a regular cadence will stack up and deliver incredible overall results.
4. Focus on creative solutions
This may seem a little generic, but all too often we constrain our thinking with existing ways of working.
As an example, one company I have worked with wanted to get a complex developer platform online quickly. The engineering team drafted a plan to build a complex infrastructure, complete with APIs, and a difficult to understand process for using it.
The founder responded with “just put a damn web server online and let people upload files”. He was right: as a minimum viable product (for a young, and potentially experimental project), he wanted to focus on shipping something that worked.
As Reed Hoffman, founder of LinkedIn once famously said:
“If You’re Not Embarrassed By The First Version Of Your Product, You’ve Launched Too Late”.
Reed is right. Be like Reed.
5. Build a hackable culture
If there is one thing I have learned about innovation over the years is that you can’t predict where it comes from. One such example is Jack Andraka, who invented a cheaper and more effective pancreatic cancer test when he was at high school.
You can’t instruct someone to be innovative, but you can build a culture that encourages and allows people to innovate. Innovation requires permission to flourish, and to accomplish this, you need to encourage and allow people to produce interesting hacks that do interesting things.
Encourage your teams to explore new ideas, build them, and demo them. Encourage people to hack on and improve products and services as proof of concepts. If you have a permissive environment that encourages people to hack, explore, and be creative, you will get that same kind of ethos when you create production products and services.
This can be nerve-wracking for some companies because it can feel like it encourages people to challenge the norms of the company. It does, and that is a good thing. Part of being a hackable culture is to actively encourage people to call you on your bullshit and propose better, more efficient, and more interesting solutions.
I would LOVE to hear your thoughts here. What do you think of these recommendations? Do you agree or disagree with them? Can they be improved? How else can we build better things? Share your ideas and feedback in the comments below…
The post Work Smarter: The Cocktail of Simplicity, Manageable Adversity, and Muntzing appeared first on Jono Bacon.
Now that Ubuntu phones and tablets are gone, I would like to offer my thoughts on why I personally think the project failed and what one may learn from it.
We started by defining the work items for the week and setting up some other HiDPI laptops (Dell XPS 15 and XPS 13 mostly) we got from the office 
![[RSS 1.0 Feed]](common/rss10.png){kind=small}
![[RSS 2.0 Feed]](common/rss20.png){kind=small}
![[Atom Feed]](common/atom.png){kind=small}
![[FOAF Subscriptions]](common/foaf.png){kind=small}
![[OPML Subscriptions]](common/opml.png){kind=small}
![[Hacker]](common/hacker.png){kind=small}
![[Planet]](common/planet.png){kind=small}
.jpg){kind=link}
