Originally published in American City Business Journals
By Bill Sinclair
As blockchain rapidly advances from a concept to a reality that can underpin the financial services industry, countless startups are building services that will work on the distributed ledger technology to gain an invaluable first-mover advantage.
That leaves executives facing a crucial challenge as their teams scramble to write great code: How do you build workable technology when the underlying technology is still being developed and refined?
The growth of blockchain feels like a gold rush in the financial services world. For example, the owner of the New York Stock Exchange is developing a regulated bitcoin market, JP Morgan Chase & Co. is building a blockchain platform for issuing and trading securities, and Australia’s stock exchange is shifting over to a blockchain-based system by the end of 2020.
At the same time, countless fintechs are building apps to perform specific services that work with blockchain, essentially developing leading-edge technology to run on leading-edge technology.
At SALT Lending, we’ve created a platform where individuals and companies can leverage blockchain assets to secure cash loans. Our journey has taught us some tricks that others can use to navigate these choppy waters — both in terms of perfecting the blockchain as well as the technology on top of it.
The only way we’ll get the best results is to apply some of the best practices in software development today.
From micro-services to micro-strategy
The days of developing monolithic software using a waterfall approach where a team is siloed on a massive software project over six months or a year are over.
Now, agile development is in vogue, where firms often build small modular components of an overall ecosystem —called a microservices architecture — often in a series of short sprints that last just a few weeks each.
However, too often agile development results in constant panic, fire drills and poor definition of requirements. In addition, the traditional microservices approach can result in inefficiencies — too many places where code is repeated and complexities create a spaghetti bowl of technology and dependencies often referred to as the microservices premium.
A more efficient approach is to follow a strategy where the focus is on what’s actually happening, rather than working on a series of single-function services.
Scalable bundled services, sometimes referred to as microliths, will meet a specific business need rather than a specific technology need. For example, teams might work on all services related to user accounts as one service, or they might bundle all billing-related services into one effort.
Developers gonna develop — let them
For this approach to work effectively, projects are ordered based on business need. The goal is to advance the product being used by customers in ways that will advance the business; it’s not development for development’s sake.
A key aspect to this is respecting the different roles of product and development. Product should define problems while developers define solutions. Product must resist the temptation to push developers to take a specific path and instead focus on complete definition of the problem or business objective.
For example, rely on your experienced developers to indicate when it makes sense to use a different language or technology for a task. As Apple’s Steve Jobs famously said, “It doesn’t make sense to hire smart people and then tell them what to do; we hire smart people so they can tell us what to do.”
Startups have limited resources, so developers should also make sure not to waste scarce engineering hours by reinventing the wheel. Using specialized tools already created by other companies and the open-source community are more efficient than building everything in-house. Further, in spite of the efforts of a product team, some problems are simply not well-understood in the early phases of a product and getting that product in a users’ hands is often the best way to gain clarity.
At SALT, for example, we use an authentication mechanism developed by another firm because that particular function needs to be hardened and is not part of our differentiated offering. When using a vendor, connect with their development team to inform them about extensions or wrappers you are adding to their tool for two reasons — they may incorporate your needs in future versions of their software, and their engineers might ensure that future updates will still work with your additions.
Leaders and developers should constantly undertake build vs. buy decisions. Startups can only afford to build those aspects of their service that are key differentiators in their offering compared to competitors. This process is often most difficult for experienced engineering teams to accept but it gives them the opportunity to use their creativity and experience on more core parts of the product offering.
Done right, a scalable microlith strategy speeds development times, allowing for the continuous improvement and delivery of new solutions and services. Once each development project passes internal tests and reviews, it can be released to users to gain immediate feedback about what’s working and what needs further refinement.
To get the best results, leaders must empower developers to discover new things and push boundaries, giving them space for professional growth where they can learn the new skills they will need to meet emerging challenges.
Even amid the shifting sands of evolving technology, an approach that gives engineers ownership of finding the right solutions will keep your team on the leading edge of the next new thing.
Bill Sinclair is Interim President, CEO and Chief Technology Officer of SALT Lending.