You are now being redirected to Orchard Platform Markets, LLC.
If you aren’t redirected in a few seconds click here.
You are now being redirected to Orchard Indexes.
If you aren’t redirected in a few seconds click here.

Subscribe to our Newsletter


  • Investor Portal

  • Originator Database

  • Manager Database

If you forgot your login email, please contact your Orchard Account Manager or

Engineering Differently: The Attraction of Startups


Why traditional financial service firms are having difficulty competing with technology startups for talent

Figuring out how best to approach fintech has many traditional financial institutions scratching their heads. According to a report earlier this year, almost 60 percent of them are developing fintech capabilities in house. Of these, only 2.8 percent say they’ve successfully embedded innovation into their company cultures. Even “moderately structured” fintech initiatives challenge these companies; less than a third (29.2%) have managed to implement such projects. Building a creative culture of innovation within a large, risk-averse institution is turning out to be a much more complicated problem than many of them expected.

 Good culture and good software are interdependent and sit at the foundation of a great company. Unfortunately for large institutions, creating an in-house technology lab, resetting culture by relaxing dress codes, offering a flexible vacation policy, and outfitting the office with the latest startup trappings, are the easiest—and in my view, least important—pieces of the puzzle. All the flextime, craft beers, and protein snacks in the world won’t address the proverbial elephant in the beanbag chair; legacy technology stacks.

A common misconception about startup culture

Many of the cultural stereotypes of technology startups—competitive ping-pong, logoed hoodies, and cold-brewed coffee on tap—are well represented at Orchard. And sure, these perks can be attractive to potential hires. But we’ve found that, above all, new hires—engineers especially—value cutting-edge technology, nimbleness, autonomy, being empowered to make immediate contributions to the team from day one, and getting code into production quickly and often.

 The bottom line—and this holds true across the entire tech industry, not just our little ‘fintech’ slice of it—is that while the cultural perks are nice, for most of us, the real joy is in writing code and releasing it into the wild. The most talented people want to either found or join organizations where they can not only make a direct impact on the engineering team but where the technology they’re creating has the potential to scale massively and affect the greatest number of people. Programming isn’t just a way to earn a paycheck. We want to change the world.

The problem at older financial institutions? They are older financial institutions

It’s easy to dismiss big financial institutions as slow and sclerotic compared to startups. In reality, it’s not even fair to compare the two. Traditional banking and financial service firms operate under very different constraints and attract an entirely different type of employee. An engineer who is best suited for a startup likely won’t be a good fit at a traditional firm and vice versa.

 Legacy processes, ancient programming languages, and multiple, interdependent systems have a lot of inertia at most large financial services firms—some even predate the internet. Codebases initiated by now-retired knowledge silos have rotted, to be tweaked by new hires. The codebases are also often monolithic, making rewrites harder and riskier—and rightfully worrisome to engineering managers. Imagine copy/paste tweaks compounded over decades! It’s not exactly fodder for rapid innovation or intellectual growth.

 Large institutions also have onerous compliance requirements around releases. Typically these are high-ceremony releases where multiple—different but mutually dependent—systems are releasing on the same night because it’s impossible to release any of them independently. They are also scheduled periodically (like monthly or quarterly) because the releases are massive and can’t be done on-the-fly, and they’re massive because all of the legacy systems are so deeply, deeply interconnected.

 For most engineers, this is amazingly frustrating. Rigid freeze dates. Testing. Then User Acceptance Testing (UAT) and requirements around Service Level Agreements (SLAs) and SLA windows. You might have a three-day window to complete the release, and then, late in UAT, something pops up in some unrelated code, and the release ends up getting scrubbed and rescheduled for the next month.

 It’s not unheard of at some of these organizations for teams to keep projects in permanent UAT. When release procedures are too arduous, people will look for ways to work around them to get something—anything—released. By avoiding scheduled production releases, they can release updates as frequently as they like because they are technically still in beta. And yes, this completely defeats the purpose of testing. But, for a lot of people, it can be incredibly frustrating to be stuck in a gigantic machine that doesn’t really move. Or, as one engineer who recently joined our team put it: “Writing code that’s never released sucks!”

If it walks like a duck

Open source libraries, modern software design, the availability of cheap hardware, and the support of venture capital have provided the foundation for the current explosion of startups focused on developing financial technology. These attributes make them a big draw, attracting both top engineering graduates, battle-tested coders, and recent MBAs alike.

 This well-documented ‘brain drain’ from Wall Street to Silicon Valley has large financial institutions on the defensive. In an attempt to stop the talent pool from flocking to startups, many are promoting the adoption of features previously unique to those smaller technology companies. However, as I’ve mentioned, they’re finding that simply calling something fintech or claiming to take a “fintech approach” doesn’t make it so.

 In reality, the fear of breaking legacy systems continues to limit the flexibility their engineers actually have, and desperately crave. It discourages them from trying new things, forcing them to issue patch upon patch instead of rolling out new products utilizing the latest technologies.

 Nimble systems, flexibility, and rapid iteration look good in print, but ultimately, they find themselves attacking the same old issues with the same old methods, and not surprisingly, realizing the same old results; interdependent systems that, over time, become increasingly more fragile, more difficult to update and repair, as well as more frustrating. So while the marketing campaigns around these innovation labs may serve as a means of attracting programmers emerging from school, truly talented individuals tend to see through the marketing spin relatively quickly after joining and almost immediately begin looking for new opportunities.

Engineering differently

When it was time to start Orchard, everything from our technology stack and team structure to our hiring practices was developed in response to having had a very similar experience, early in my career, to what I just described. And everything we do supports independent thought, teamwork, rapid iteration, the open transfer of knowledge, and flexibility at massive scale. All things I learned after leaving financial services and working on advertising technology.

 New team members are given access to everything they need to get started on day one and are encouraged to jump in and experiment without worrying about breaking things. This is possible because of our microservice architecture, automated and on-demand development environments, adherence to current best practices, and the strength of our team.

 We seek out engineers with a demonstrated intellectual curiosity that are independently interested in mathematics and programming and who bring these interests and experiences wherever they go. People with the kind of passion for programming that doesn’t clock out at the end of the day. We take our work to happy hour.

 I’ve found that a lot of folks suited to work at the larger institutions lack mental elasticity or an interest in programming beyond a paycheck, and that’s what we’re filtering for in our hiring practices. What I mean by that is 9-5 programmers tend to become complacent over time, locked into using a specific toolset, and have little interest in pushing themselves to learn anything new. It doesn’t mean they are a bad programmer or person, just that they would probably be better suited to working at a larger institution.

Is There an End to ‘Brain Drain’ in sight?

Engineering and technology have historically been viewed as cost centers at large firms, and that mentality is not something that can be reversed overnight. Also, while good-intentioned, creating internal fintech or technology labs typically has the unintended effect of isolating these people from the rest of the company, rather than making them a core facet of doing business. But most importantly, even as traditional financial firms are becoming less lumbering, old practices and legacy systems persist, and that will continue to put them at a distinct disadvantage when trying to attract top-level talent.

 In future articles, we plan to dig more deeply into specifics of how we think about building a great company along with examples of challenges and solutions specific to Orchard but also applicable to most businesses and startups across industries.