Discover more from Entrepreneurial Engineer
What Breakthroughs We Can Do Right Now, But We're Not? (27/30)
I'm writing 30 posts in 30 days. This is number 27.
Today is the February 18, 2021. It’s been 10 months since I have started working from home exclusively. I fully expect to hit 1 full year of work from home by April 2021. I have been back to the customer’s site on some days since the pandemic situation started improving in August 2020. Overall, as in like 95% of the time, it’s work from home for me.
I’m not alone. Many people and companies have shifted drastically to remote work due to the pandemic. Once this pandemic is over, I’m sure there will be three main work arrangements.
A portion of them will switch back to the way things were before pandemic.
Another portion shifting to something like 50-50.
And the last portion permanently switching to this arrangement.
Let’s assume the entire workforce divides itself equally into three portions: 1/3 default onsite, 1/3 50-50. 1/3 default work from home. That’s a hugely different world compared to the one pre-Covid. I’ve been thinking, was there anything material, before Covid-19, that stopped us from having our work arrangement this way? The answer is, clearly, no.
What Breakthroughs Are Possible But We Don’t Dare to Do?
We just kept the way we worked the traditional way for years out of pure inertia and fear. Having even 10% of the workforce working from home as default during the pre-pandemic times would already be hailed as a breakthrough. Now, that number seems too low going forward.
Which brings me to ask: what other breakthroughs are totally possible but we don’t dare to do it out of fear and inertia?
My work consists mostly of writing CRUD software to help with automated workflows. My ambition is to build a 1 million ARR micro business. So, I feel the most confidence in asking and answering that question in the areas of software, workflows, and building a micro-business.
Communications is a Bug
My answer to the question of “What other breakthroughs are possible right now in software development?” would be the removal of communications and coordination in building stuff.
That idea seems ludicrous on the surface. Of course, building requires people to communicate. Why wouldn’t it be? Building anything, be it software, or business, we need to communicate to exchange key information. Without key information, we either fail to build or we successfully build software or businesses that fail. So what gives?
I’m reading Working Backwards by Colin Bryar and Bill Carr right now. And I stole my answer from them. Or more specifically from Amazon. Working Backwards is a book about the inner workings of Amazon by actual former Amazon executives who had close proximity to the founder, Jeff Bezos.
In the book, Bryar and Carr recounted how after a period of accelerated growth, Amazon started to feel the strain of communications and coordination across different groups just to get anything done. I quote
At last we realized that all this cross-team communication didn’t really need refinement at all—it needed elimination. Where was it written in stone that every project had to involve so many separate entities? It wasn’t just that we had had the wrong solution in mind; rather, we’d been trying to solve the wrong problem altogether. We didn’t yet have the new solution, but we finally grasped the true identity of our problem: the ever-expanding cost of coordination among teams. This change in our thinking was of course nudged along by Jeff. In my tenure at Amazon I heard him say many times that if we wanted Amazon to be a place where builders can build, we needed to eliminate communication, not encourage it. When you view effective communication across groups as a “defect,” the solutions to your problems start to look quite different from traditional ones.
— Bryar, Colin; Carr, Bill. Working Backwards (p. 61). St. Martin's Publishing Group. Kindle Edition.
The emphasis in the quote is fully mine. The teams at Amazon actually tried to make communication across different teams to work. But after trying so hard to make communication work, they decided to try a different tack: total elimination of communications altogether. In case, you think that elimination of communications also means zero exchange of key information, wait till you read the next quote on the same page.
He suggested that each software team should build and clearly document a set of application program interfaces (APIs) for all their systems/services. An API is a set of routines, protocols, and tools for building software applications and defining how software components should interact. In other words, Jeff’s vision was that we needed to focus on loosely coupled interaction via machines through well-defined APIs rather than via humans through emails and meetings. This would free each team to act autonomously and move faster.
Bryar, Colin; Carr, Bill. Working Backwards (p. 61). St. Martin's Publishing Group. Kindle Edition.
Again, the emphasis is mine alone. Before I move on, I want to point out Bryar and Carr listed measures other than API to help with eliminating communications and, what they called, organizational dependencies. Measures such as New Project Initiatives, and single-threaded leadership. I won’t go deep into them in this post. Just go get the book.
I’m suggesting that the world is ready to do what Amazon realized in late 90s and early 2000s. Different organizations may take different measures, but the technology and infrastructure is there for us to take the same leap that Amazon took — elimination of communications.
In fact, I would suggest that one reason for Amazon’s success — and other similarly ground-breaking companies — is that they were willing to take the next step in the evolution when it’s called for. Whilst their competition persisted in staying where they were. The natural next step in the evolution of work is to eliminate communications of the old kind — exchanging details via emails and meetings.
Next Step: a Proposed Model to Eliminate Communications in my Work
In my next post, I will write out an outline of how I would implement this idea in my current customer-facing services-based micro-business. I want to warn you upfront, I intend to do it differently from Amazon.
And, I have to do it differently. Amazon is a bigger entity than mine, but Bezos had more power that I ever have. He could mandate his employees to adopt service oriented architecture and APIs, but a lot of my communications is between me and my customers. I cannot simply make my customers follow my new way of doing things. So, don’t be surprised that I cannot make APIs between myself and my customers to exchange information. If you’re interested about my proposed model, keep an eye out for tomorrow’s post.