You have 1 article left to read this month before you need to register a free LeadDev.com account.
The right idea might come at the wrong time. Here’s why the most technologically advanced solution might not always be the right one.
As engineering folks, we’re often tempted to push the most forward-thinking, technologically advanced solutions to our problems. But sometimes, the simpler, well-established solutions can be the most effective.
Don’t get me wrong – new, cutting-edge ideas are great. But what if people – including your staff, customers, and senior leaders – aren’t ready to take advantage of them? They might provide a perfect solution in a year, two years, ten years… but if you’re too early, that’s the same as being wrong.
Here I’m going to share two examples of times I pushed for the most technologically superior solution too early, and was wrong.
Example 1: Abandoning files and folders for Adobe Creative Cloud too early
A little while after I had started working for Adobe, Dropbox entered the market with a very simple value proposition: ‘It takes a folder of files and syncs them across all your devices’. The Dropbox team had worked incredibly hard to accomplish this seemingly ‘simple’ thing. So, it wasn’t surprising that not too long after we started working on Adobe Creative Cloud, leadership asked what our file syncing strategy would be.
There were a few schools of thought at the time about how to solve this problem. The first two, although not perfect, were straightforward enough. The third solution – and the one I was lobbying for – seemed technologically superior. Let’s take a look at each one:
Solution 1: The first option seemed obvious: use Dropbox. They already solved the file and folder syncing problem and were achieving incredible viral adoption. Most of our customers were already Dropbox users so this could have been an easy sell. One of our principal engineers was able to prototype an integration using our API in a couple of weeks.
Solution 2: There were some senior leaders that were concerned about lock-in and wanted to ‘own’ the customer in this scenario. Their preference was for us to either build a Dropbox-like service or find a white label version we could use. Neither of these seemed appealing as they would require significant engineering effort to pull off and take resources away from building our core service.
Solution 3: Even though I supported the Dropbox integration, I was also lobbying for a third, more future-forward option: forget files and folders altogether. From the start of the project, we had designed our API around a document store model as opposed to an hierarchical one. If we were truly a cloud service, why did we need to replicate the filesystem for our customers? In my opinion, services like iTunes had shown us the way. With search and deep metadata, users wouldn’t need to manage files themselves anymore. In fact, customers wouldn’t be thinking about ‘files’ anymore – they’d be thinking about their content.
After putting my solution forward to senior leaders, I was politely shot down by a colleague who had already gone down this route with a previous company, and it didn’t work. Customers weren’t yet ready to abandon the UX they’d already mastered. The value being offered had not yet reached a level that a radical change in expectations would be accepted.
I naively believed that we were in a position to change people’s thinking. Fortunately for customers (and unfortunately for several teams, including my own, as it meant a lot of work), the decision was made to acquire a small file syncing product and morph it into the Creative Cloud Desktop application.
Despite its many issues, it was the right decision for customers at that time. Years later, Adobe would start promoting the idea of cloud native content. But an idea that’s presented too early is still the wrong idea.
The context that I had missed was user readiness. Like many engineers, I saw the possibilities and advantages but missed the critical element: customers weren’t feeling enough pain (yet) around the problem, and weren’t ready for the conceptual leaps I was advocating for.
Example 2: Moving from desktop applications to the browser too early
Atwood’s Law (2007) states that, ‘Any application that can be written in JavaScript, will eventually be written in JavaScript.’
This law seems uncontroversial today with the number of applications that have been built using JavaScript. However, back in the early 2010s, the performance of JavaScript runtimes was nothing like it is today and there were still many doubters.
I was still working for Adobe during this time. My team fully believed in the web and web technologies but Adobe as a whole predominantly believed in native desktop (and mobile) applications.
Our team was undeterred and focused on making our web-based asset management application as performant and extensible as possible. We built a JavaScript-based plugin system and worked with multiple teams to build editor plugins for their content types. This approach allowed us to move quickly and extend the desktop applications to the web. One day, one of our senior principal engineers asked me to come to his office for a demo. My jaw dropped as I saw the layers of a Photoshop document being manipulated inside a browser! This engineer had used Emscripten to bundle Photoshop code inside a plugin for our app. This was the future we’d envisioned and my mind was blown.
We advocated for working with the engineer to get his plugin production-ready and release it at the next Adobe MAX conference. But once again, we were too early.
Emscripten still had limitations and our leadership didn’t want people trading the desktop applications for the browser. They were fine with a cloud backend but the frontend still needed to be a native application. Even though more and more people were using web applications that replaced desktop applications, the internal assessment was that customers wouldn’t be able to use a web browser for the image and video editing workflows.
Again, I disagreed but I was wrong at that time.
The potential was there and JavaScript engines would improve. Emscripten would make way for WebAssembly. Adobe would eventually pay $1.3 billion to acquire web-based video editor Frame.io. As for the dream of using Photoshop in the browser, Adobe is now making that a reality and it will be free.
But the context I was missing this time was business readiness. While the company had managed to turn the ship from shrinkwrap licensing to subscription licensing, they weren’t yet ready to go all-in on Atwood’s Law.
Reflections
Ideas don’t exist in a vacuum. The context surrounding those ideas plays a key role in their adoption. For ideas to take off, developers, customers, and business leaders need to be able to embrace them. The moral for technologists, as always, is that the technologically superior solution may not always be the most successful one – especially if people aren’t ready to take advantage of the benefits.
