Have we put the cart before the horse when it comes to DLT?

When talking Distributed Ledger Technology (DLT), we (the collective we) spend a lot of time discussing the industry or the app that is going to drive mass consumer adoption.

Some people believe that it’s gaming with its highly addictive collectible nature. Others believe that cannabis and agriculture supply chain with its push toward hyper transparency will be the driver. While others still believe that the financial world needs to rally around the tech before we can have true adoption. And while these discussions are important and meaningful, in all of it, we’re somehow leaving out an entire audience, the developer.

The developers have become synonymous with the end-user despite the challenges, motivations, and needs being entirely different (#cartbeforethehorse).

We’ve forgotten that developer adoption is critical to the success of any emerging technology and Distributed Ledger Technology (DLT) is the new kid on the block.

User adoption comes with a playbook, developer adoption doesn’t .

You can’t discuss user adoption without discussing the Diffusion of Innovation. The theory, popularized by Everett Rogers in 1962, outlines the rate at which innovation/technology/trends are embraced by the communities that will adopt them.

It’s essentially a playbook for understanding the lifecycle of your product and, when used strategically to inform your roadmap, can be an incredibly powerful tool.

But where’s the playbook before the playbook? The complicated, nuanced, wild west world where developers need to rally around the technology in order to build with it?

I’ve decided to call this period The Developer Courtship (trademark pending… ok not really) and I’m here to help write the playbook.

Want to woo a developer? Start by understanding what the challenges are.

Why is developer DLT adoption so difficult?

The tech is new (and unproven).

Risk is higher when there’s no precedent set. Developers who are willing to jump in and build are up against difficult platforms that have challenges scaling to meet demand and keep TPS low. That kind of frustration trickles out, making it a much riskier bet for others.

Change is hard.

Organizations need to keep moving. They need to focus on development and growth. Changing underlying systems and processes from an infrastructure that is “good enough” is a challenging thing to rally around; It means they’ll need to slow down or stop delivering new features for users. The investment in new infrastructure needs to be truly worth it in the long run.

Adoption is a burden.

DLT will revolutionize the way that individuals and organizations communicate and collaborate within a system. In order to have that kind of impact, you need every part of that system involved. Organizations aren’t interested in taking on the burden to connect all the players unless they feel like they have partners in the process.

A Playbook for The Developer Courtship

In order to get past these challenges, we need to see the road ahead and provide the map to traverse it.

How?

Be relevant.

Understand their problem and their opportunity.

A two person development team vs a fully staffed product engineering group aren’t facing the same challenges, nor do they have access to the same opportunities. You need to take the time to understand the individual needs of that organization and then put in the legwork to understand what they (specifically) can achieve by adopting DLT.

Help them be agile

DLT is powerful technology that connects many different players. You can’t swoop in and change everything all at once (while simultaneously running existing solutions). Help development teams be agile. Help them see the possibilities by cutting it down to the most impactful opportunity. Start by choosing a piece of the business… then choose one piece of that piece of the business… then get to work helping them build a scenario that fits this small area and tackle it up from there.

Be excited.

If you’re slinging new technology, no one can see the opportunity better than you can. Developers want to develop solutions and build meaningful, cool things. Stay motivated to help them. Don’t let them get to the party and then mingle around on their own. Keep them engaged by keeping yourself engaged.

Conclusion

We talk to developers all the time about Tupelo who first want to know why this tech… and then want to know how to use it… and then want to know when they can jump in and try it. There is a path to getting developers excited to make things with Distributed Ledger Technology, but it takes time.

When you make that time to genuinely help developers solve problems and seize opportunities, you can propel technology forward.