How Banks Will Get the Tech Talent They Need

Big banks and financial companies have a shortage of technology talent, just when they need it the most. In some cases they have outsourced and economized to the point where they can maintain their old systems, but not create new products. In other cases, they have built good teams, but they are losing key individuals to fintech startups with a different culture.

The Short Answer

All we have to do to deliver talent at the scale required is:

The Long Answer

There is hope. Any multinational company has solved the problem of getting talent globally and working in distributed teams, at some level. The more they focus on management skills, the more they can work in a distributed fashion. For example, State Street Bank tends to have people working in large co-located offices, although they have these offices in several continents, and people are often forbidden from working outside these office centers. This relatively low level of distribution is pretty common for bank IT departments. SAP, which is in the business of management tools, looks quite different. When I do a conference call with SAP, I often find that the participants in one call are on three different continents. Accenture and IBM don’t even provide offices for many of their staff. So, there is a spectrum and a migration path from centralized to decentralized.

The more centralized organizations have difficulty recruiting and holding youthful tech experts. This problem gets worse if they are recruiting for “IT”, because IT is a cost center, not a profit center, and they won’t just throw money at it. As a CEO, I know how hard it is to invest in a cost center. They are more likely to save money on IT, and then spend it on fintech acquisitions that have managed to position IT as a product and a profit center.

If we want these more centralized organizations to break through into the new Web service ecosystem, we need to give them talent. We will bring in a battery of tactics under the headings of automation, simplification, globalization, centralization, and transformation.


Eventually, we will need fewer people making software. The process gets more and more automated, and productivity goes up. In my career, I would guess that development productivity has improved about 10X. This fact has been obscured because we need more than 10X as much software, but now we are hitting the part of the exponential growth curve where productivity will become obvious. Investments in automation will yield results.

We can already see that continuous development teams can overrun their product managers and start producing software that isn’t fully designed, tested, and launched. We are bringing in tactics to boost and stabilize the product management role.

We can use automation to include a wider variety of existing teams. Automated testing and microservices can help us include teams with lower levels of skill. Each change goes through enough review and test steps to give the team time to meet requirements. During this time they won’t block releases from teams working on other services. Ultimately, the same type of testing and review process will make it possible for us to test and review software that is written mostly or entirely by computers.


I started working on my own brand of “continuous agile” because I use globally distributed teams that do not meet as often as Scrum teams. The continuous process is simpler with fewer meetings. When we move to a microservices architecture and “No Ops” model, the team becomes simpler. We do not need a fully “multifunctional” Scrum team. Getting all of the functions into those teams and coaching them to be “self organizing” is a difficult and time consuming process. Instead, we find one good “tech lead” who can build a set of services, and that person pulls in talent as required.

Because the process is simpler and the teams are simpler, they are easier to build. So, we can throw them together faster. This gives us a path to offer scalable capacity to organizations that are bound up in Scrum teams.


A distributed team works if all of the team members are literally working on the same thing. We use continuous integration and continuous delivery to make sure that all of the team members are contributing to the same build and looking at the same build.

Given the continuous shared build, we are free to put together a globally dispersed team. I often throw together a “blended team” that can include my experienced distributed team guys, client staff, outsourcers, and contractors recruited for the needs of this specific project.

I do have some tricks for throwing these teams together. For example: Get a tech lead; start with automated builds; advertise and recruit globally and aggressively, add people on two week trials. One of my tricks is to overstock the team at the beginning of the project and then weed people out. At the beginning of a project, everyone is a beginner, so you don’t lower your average experience by adding people. I am also getting off to a good start with ten day co-located launch sprints in nice locations.


One of the megatrends of the cloud era is the tendency to centralization — moving IT activities into a smaller number of big datacenters and a smaller number of productized or even “consumerized” systems. If we think of a finance product as a big bag of Web services, a lot of these services will be provided centrally. This is why a lot of banks are setting up consortiums to build shared services (for example, blockchain services that provide a shared ledger, or reference data services that keep track of entities and securities). At one fintech conference an experienced executive stood up and said “there should be only one back office.” That would free up a lot of capacity.

So, my proposal is to set up a “Service Market” group that just finds services embedded in banks, qualifies them as being close to best of breed, and packages them for sale as shared services.


A lot of companies have gone through a long and painful “transformation” from Waterfall development to Scrum agile. Now we are asking them to make a similar transformation to Continuous agile. We can make the next step a lot easier and lower risk.

We can start by running Conway’s law in reverse. The structure of your products and systems dictates the structure of your organization. If you do big, synchronized software releases, you need a big, hierarchical organization to make sure that all of the pieces come together at the same time. That requires a lot of management attention, including synchronized training, and maybe even the dreaded “culture change.” When we break the releases into smaller services, the management structure goes away, and some of the need for synchronized change goes away. We have less management work, and we can change more incrementatlly.

We can make this process easier through automation. If we deliver a nice machine to build, test, and deploy code that obviously works, it is hard for people to opt out on the basis of culture or opinion.

People will need to adapt, and we can help them. There is a significant community of professionals that just work on Scrum agile, with various techniques to help teams and organizations. We can use these people for Continuous agile.

SaaS entrepreneur/engineer. Founder of MAXOS, Real World DeFi. Previously founded Assembla, PowerSteering Software, on team at SNL Financial.

SaaS entrepreneur/engineer. Founder of MAXOS, Real World DeFi. Previously founded Assembla, PowerSteering Software, on team at SNL Financial.