Innovation is dying and it's our own fault

May 28

Mark Piper, Principal Explorer

13 May, 2024

Over the last 20 years I have signed more Non-Disclosure Agreements than anyone should be comfortable with. Back of the envelope math suggests I have signed hundreds of them.

I have signed these agreements, not because I enjoy reading the fountain of fine-print that expresses all the different ways that secrets are important and that intellectual property must be protected at all costs - or because I love being on the hook for what must be millions of dollars of financial penalties by now. No, I don’t even thrive with having ten thousand secrets in my head - but it’s simply the nature of the consultant's job.

As a consultant, you spend a lot of time walking into a place, looking behind the curtain and examining how the sausage is made. If you are a good consultant, your work is focused on helping with improvements. In my case, as a security consultant, I was focused on understanding how systems are built, data is protected and how we can improve the overall security of the solution via offensive security testing.

I’ve read the source code. I’ve read the configuration scripts. I’ve read the architecture documents. I’ve reviewed the business cases. Mined the mountain of vulnerability data. I’ve logged into the servers. I've accessed the secrets. I have seen the entirety of the sausage.

I’ve seen the most sensitive IP of some of the largest enterprises in the world.

I don’t say this to brag, nor is this a setup to breach any of the NDAs I have signed.

I say this because I think it puts me in a unique position to understand what IP firms hold and it’s real vs perceived value.

I think it’s time to examine the obsession, the over-reliance on, and the myth being perpetuated around intellectual property and its role within innovation across industry.

You Got a Fast Car

If we look at the last 30 years of progress online, very few of the major advancements are the result of closed ecosystems. In fact, I think we can go as far to say that almost all significant technological advancement of the last 30 years has occurred in the open.

Either via academia (often via public / private partnerships), via Open Source or through really rough shared experiences, we have evolved and innovated as a society online.

I want to take a moment to set a scene.

Many of you reading this may have been in briefing meetings before. The kind of meeting where your boss has given you approval to give the consultants your deepest darkest secrets. You sit down with them, knowing you're about to reveal the messy underbelly of your operations. The truth of your environment. With a steady voice, you say:

Everyone thinks we have this seamless, state-of-the-art solution, but the truth is it's held together with outdated Bash scripts, a mishmash of Python and Go microservices, and manual processes.
Our data pipeline is a chaotic blend of legacy systems, scattered shell scripts, ad-hoc APIs, and cron jobs that haven't been updated in years.
We’ve been so focused on keeping things running that our infrastructure is a patchwork quilt of quick fixes and band-aid solutions.
We're using an ancient SQL database alongside a newer NoSQL database, and they barely communicate. Data consistency is more a hope than a reality.
Invoicing is still a manual process every month, relying on Excel sheets and email approvals.
Our incident response plan? Non-existent. We have no idea if we could restore operations if a major incident occurred.

The consultants listen without a hint of surprise. That unnerving calm. Did they even register what you said?

They did. The lack of reaction is because, to them, your setup is just another Tuesday.

This is the truth. Your stack is almost never novel in any significant way. The enterprise solution you have established is the same as everyone else.

Your culture might be different. You might be a better place to work. You might have happier teams than the ‘other guys’ but the stack, yeah, that stack is going to be roughly the same. Those manual processes? Seen them before. The lack of restoration knowledge? BAU. FTP in use in 2024? You are not alone.

This is the fact that almost every organisation I have worked with over the years absolutely hates to hear:

Your solution is not unique.

I’m not saying the solutions are wrong or bad. In fact, they're often great and right on target to solve the businesses challenges! The end user or customer experience is often amazing!

The solutions however; are just not that unique.

Within enterprise, organisations generally build solutions from blocks of enterprise friendly components. This works because it helps ensure safety in your solution and also availability of skilled talent over the lifetime of the solution. Whatever that solution is.

This is the myth that we need to bust. We need businesses and staff to stop thinking that they are innovating when in fact, they are deploying what are fairly standard enterprise solutions most of the time.

Maybe Together We Can Get Somewhere

There is a trend I have observed over the years in that open sourcing solutions and giving back is becoming less and less accepted in the world. Whether it’s code, architecture or documentation, there is this obsession within enterprise that if it was produced on company time, it must be held as Intellectual Property by that company.

This is a fairly understandable position, the company after all took the time to figure out the solution and invested in precious money, time, compute resources and human beings to make the thing be a thing.

But that thing is often built off already open software and specifications. By sharing, or being open about lessons learnt during development or deployment, the underlying stack you have built on may improve for everyone. This in turn, may lead to further improvements from other teams that you and your business may benefit from.

As the old saying goes, a rising tide floats all boats.

There are, of course, many instances where an open solution is the wrong call and there’s absolutely nothing wrong with leveraging proprietary or closed solutions to meet your needs. I’m not at all suggesting running your business in an entirely open fashion is the right move.

If we want a good, current example of what I’m talking about right now we need to look no further than current innovation relating to AI. This has exemplified the situation on how innovation is happening in the open rather than behind closed doors.

If you spend any time on Hugging Face or Kaggle you will find iteration after iteration of models, datasets and applications exploring all manner of use cases for AI. This iterative process is in part what has pushed the speed of LLM advancement forward in the last 24 months.

The result is a morphing mass of models that people have experimented with and adopted across solutions before fine-tuning, tweaking or heavily modifying the model and returning it back to the open for further academic scrutiny and tinkering.

Sure, Google has released Gemini with a trillion+ parameters and OpenAI has released GPT 4o with agents in the backend (remember folks, if it’s free…) but their own advancements are from computer science disciplines being discussed in the open. Most of the time.

There was a time when it was quite reasonable and acceptable to openly discuss the solutions we are building, how we are building them and in turn giving back to open projects to help not only our own businesses, but others improve the stack we’re working with over time.

I’m not sure when things changed. When we decided that everything being built was the equivalent of a state secret, but I implore you to stop treating it as such.

Innovation occurs in light. Not in darkness.

When we attempt to innovate in the dark a number of negative or risky patterns begin to appear. A few that I have observed consistently over the years include:

Over-engineering of solutions.
When there are no open architectures, code bases or patterns to compare with, it is easy for teams to over-engineer solutions and develop components that are less mature than existing solutions on the market.

Keeping it simple is being lost to time at a time where it might serve us best.

Under-engineering solutions.
Without openly discussing failure cases, we amplify the risk of repeating the same mistakes when the shit hits the fan. Shared experiences (such as regional power outages or global computer worms) keep us abreast of the reality of how systems behave when things go wrong.

If we are not discussing them and sharing experiences we increase the likelihood of miscalculation with risk mitigation.

Overinflated-inflated sense of value.
Solutions have value and that is the way it should be. The problem however, is that we often over-prescribe value to what is not really unique IP. Anyone who has done work in the mergers and acquisitions space will have a litany of stories of sellers trying to inflate their value with what they perceive to be a unique, novel and core asset which is in fact anything but. This leads to conflicts and is increasingly being understood by the market with short sellers now routinely questioning the inflated value of certain solutions. Especially around AI.
By being open, we might sooner spot the true value of our solutions and where actual IP exists before it’s too late.

Influenced decision making.
Spend time within RFP processes for a while and you learn to spot when the requirements have been written by a third-party on behalf of the procuring organisation. The sure fire way is to look for requirements that just don’t make sense, but only one provider would have the ability to fulfill the requirement.
This is not only a fun game, but an indication of conversations that are happening behind the scenes which means the innovation process might be influenced by closed sources and sticking to templates without actually innovating.

Won’t have to drive too far

This is not a call to action asking everyone to suddenly and dramatically change their way of operating. That would be unrealistic. As mentioned, there are times where very needs for confidentiality and secrecy in business is required.

But it’s not all the time.

I believe we are at a time where innovation is not just a nice idea but is required. It’s not just changes to the macroeconomic climate that is concerning, it’s what we are building and how as a result of it.

In the last 12 months we have seen more incomplete and broken solutions hitting production than ever before. We are seeing a race to solutions without critical thinking. Without true innovation We are witnessing lessons being learnt over and over again the hardway, rather than the first time.

There is a race to be novel in our solutions development. To push the boundaries. To meet customer needs and I believe that in order to meet the challenges more consideration should be given to leveraging open technologies and sharing our experiences with the wider community.

Now is the time to really review what is the actual value of that IP? Is it really novel? Is it really unique? Does it improve the world we live in? Can we do better?

When we open up, we bring togetherness to problems. We rinse away a lot of the shame and stagnation that can occur in the dark. The consultant briefings can become one of pride. Where you have excitement in presenting your solution.

Organisations become true leaders in helping others with similar problems. You don’t have to be first to solve a problem, but you can be the provider of the best solution.

Mark Piper