Specifically, I’ve been thinking about how organizations at scale build software and how difficult it really is to not only introduce change but then go one big step farther and implement that change effectively.
For those that know and have experience working in the enterprise, you intimately know how difficult it can be to deploy anything at scale and how the problem centers around deployment is much more than just technology and software – it can be, unfortunately, as much of a systemic, bureaucratic and political problem to solve as well.
I was reminded of this poignantly in a recent article by Benedict Evans who elaborated on how difficult it is to accept new technology and how easy it can be to dismiss it.
He highlighted how this is experienced within the enterprise and I marinated on this particular point for quite some time:
First of all, it’s quite common, especially in enterprise technology, for something to propose a new way to solve an existing problem. It can’t be used to solve the problem in the old way, so ‘it doesn’t work’, and proposes a new way, and so ‘no-one will want that’.
This is how generational shifts work – first you try to force the new tool to fit the old workflow, and then the new tool creates a new workflow. Both parts are painful and full of denial, but the new model is ultimately much better than the old.
The example I often give here is of a VP of Something or Other in a big company who every month downloads data from an internal system into a CSV, imports that into Excel and makes charts, pastes the charts into PowerPoint and makes slides and bullets, and then emails the PPT to 20 people.
Tell this person that they could switch to Google Docs and they’ll laugh at you; tell them that they could do it on an iPad and they’ll fall off their chair laughing. But really, that monthly PowerPoint status report should be a live SaaS dashboard that’s always up-to-date, machine learning should trigger alerts for any unexpected and important changes, and the 10 meg email should be a Slack channel.
Now ask them again if they want an iPad.
This hit really close to home as I have had more than a handful of experiences in my short career with trying to share to a larger technology team (and leadership) what was ultimately a symptom of a “generational shift” and how the process of introduction and implementation were definitely painful.
If I’m to be honest, my at-bat percent rate of successfully introducing new technology to enterprise and legacy systems is low; it’s just that hard. But if you can work through the growing pains then, as Ben shares, it is worth it.
Thankfully, we’ve been able to work with a number of design partners who understand this dynamic and who understand that any short-term discomfort is grossly outweighed by the long-term benefit.
And we are doubly-grateful because we’ve built our system in such a way that we do not have to ask them to do anything fundamentally different or difficult; access to their data is a first and powerful step on the path to a generational shift.
But what is most exciting is that we’re all beginning to see and understand the value of the capability beyond just the first and initial application. Using Ben’s words again is useful:
So, the use cases are subjective, but the capability is objective, and it’s the capability that matters. Really, the new technologies that matter give us superpowers. Is that what we’ve made this time?
Electricity is a superpower, and so are cars, and flight, and mobile. I can rub my watch and tell the djinn that lives inside to summon a car, and there’ll be one waiting at the door. We can hear, or see, or travel, in ways we could not do before. Where we go and what we listen to are secondary questions. You can’t necessarily predict the applications, but you can predict that people will like having a new superpower.
What you do with your superpower is up to you.
It’s what we do with the new superpower that has me fantasizing about a very important and exciting future.
You see, data transparency is great because it allows an individual, a team, a manager, and senior leadership better understand their resources from technological to human. It helps them understand their financial modeling and create estimates to a degree of certainty that wasn’t possible before.
But that’s just the first-line application. Liberally applying Ben’s principle thinking, what can an individual and organization do with this new “superpower” of full data transparency?
I argue that it’s much more than just better modeling and better estimation. Ultimately I think it’ll help individuals and organizations fundamentally build better software, most likely in ways that we haven’t completely thought of quite yet.
Just like Edison believed that sound recording would be simply good for sermons (i.e. a specific application) and missing the much larger utility of sound as a way of interacting with others and the world, we may feel tempted to stand in a similar (and limited) place and see data access and data visibility in terms of only making (and saving) more money.
But that’s too shortsighted, too small, and far too specific of a use-case. The liberation of data throughout the organization, from top-down to bottom-up is just the landing zone for this new superpower and we must practice using it so as to realize the full potential.
We’re grateful for the brave organizations who have partnered with us thus far to experience a truly generational shift in the way that they build software and build their business and we’re looking forward to sharing in the very rich and promising rewards.
[Ben does a better job of giving a broader context so feel free to read his article in full.]