Are product silos in a bank inevitable?

Silo thinking is often frowned upon in the industry. It is often a synonym for bureaucratic processes and politics and in almost every article describing the threats of new innovative Fintech players on the banking industry, the strong bank product silos are put forward as one of the main blockages why incumbent banks are not able to (quickly) react to the changing customer expectations.

Customers want solutions to their problems and do not want to be bothered about the internal organisation of their bank. Most banks are however organized by product domain (daily banking, investments and lending) and by customer segmentation (retail banking, private banking, SMEs and corporates). This division is reflected both at business and IT side and almost automatically leads to the creation of silos.

It is however difficult to reorganize a bank without creating new silos or introducing other types of issues and inefficiencies. An organization is never ideal and needs to take a number of constraints into account:

There are a lot of overlaps between products, services and customer segments

Some examples:

• A PFM/BFM tool requires services of all product domains

• For a professional or owner of an SME company, the split between his personal (retail or private banking segment) and professional banking (SME banking) is not that obvious

• Many products and services offered to 1 customer segment are also offered to another (e.g. a private banking customer still needs the standard retail daily banking services)

• Across domains there are a lot of common processes and features, which can be shared, e.g. user and role management, notification management, consent management, manual task management, digital signature management, document management, document generation…​

No organisation is ideal

• In an end-to-end product organisation, the Business and IT teams for a specific product are end-to-end responsible for the delivery (and improvement) of this product. This makes coordination simple and guarantees end-to-end ownership, but it also gives several issues, e.g.

  • Each product team creates its own services for reporting, notifications…​

  • A lot of overhead in skills is required (e.g. for delivering a new product you need UX designers, product managers, business analysts, web developers, back-end developers, mobile native developers…​)

  • The separation per product team can lead to inconsistent channel experiences (e.g. differences in look-and-feel between products and between different channels)

  • It leads to the creation of Product Silos introduced above, i.e. it becomes difficult to create services and products which are transversal across multiple product silos

• A solution to the above issues, is the setup of shared services. These are teams that deliver generic services, used by multiple product domains. Typical examples are the channels team (building all distribution layers), the integration (middleware) team (building all integrations between different applications and with external partners), the infrastructure and operating system team, the database administration team, the customer reporting team (managing generation of all reportings/statements to customers)…​ This means a project (or even a product) becomes a bundle of components designed, built and maintained by different shared services. While this ensures consistency and allows an easier setup of transversal products and services and a more efficient resource allocation, this comes also with a lot of issues:

  • The most important and often neglected disadvantage of this setup is the lack of commitment and ownership to the end-to-end product or service. As people working for a shared service are not directly involved in the end-to-end product, it is difficult for them to get them enthusiastic (and go the extra mile) about the end result, because for them it is just one more task in a backlog. This is even further enforced, when communication with these shared service teams is done via ticketing systems and when those teams are outsourced. At that moment, the objectives of the shared service team and the product team are no longer aligned.

  • Difficult to manage capacity of these teams. As these teams will be solicited by multiple feature teams, each having their own planning, the required capacity can become very bursty. Theoretically this should be solved by rapidly scaling up and down these teams, but in reality a ramp-up is costly as it takes time to find and train people. When this investment is done, it becomes hard to justify a ramp down a few months later. As a result, most shared service teams have a quite fixed capacity, which means that a shared service team providing 1 component might block an entire project if they have insufficient capacity.

  • Central components need to serve the common needs of all "shared service clients". Any structural change to the component (e.g. to API) will require adaptation and regression testing of all clients of the concerned component. As such shared service teams will avoid this as much as possible. The result is that shared service teams offer a standardized catalogue of services with little room for flexibility. This puts a constraint on the innovation delivered by the product teams.

• Micro-service architectures and teams associated to a micro-service try to be a compromise between full product teams and the use of shared service teams. A team responsible for a micro-service will also deliver a specific (business) function, which is usually not linked to a product or customer segment. However contrary to shared service teams, which typically try to combine people with similar skills, a micro-service team still delivers an end-to-end functionality and thus combines multiple expertises. Examples are an authorization and authentication system, a digital signature system, a pricing engine, a product engine, a recommendation engine, a credit origination service, an interest calculation service…​ This has as advantage that there is again end-to-end ownership and that commonalities between products and between customer segments can be exploited, but it can lead to technology sprawl (as each micro-service team has a choice in technology) and also here it is difficult to manage capacity (as the work to be done on a micro-service is not constant over time). This last issue can be addressed by a change in the budget allocation processes. If every micro-service team has its own fixed budget and own defined roadmap, it can use this budget also for refactoring when there is less business demand and to suggest innovations (functional or technical) themselves, when no demand comes from business product managers. This gives additional autonomy and motivation to these teams.

• Flexible organisations (matrix structures) which adapt continuously for projects. These organizations adapt themselves continuously in the need of projects. This means a project team with different profiles are combined (mixed teams of business and engineers) together for a specific period of time to deliver a project. During that period, these people are maximum (ideally even 100%) freed up of any other work, so that they can be fully committed to the project. This means ideally that during the course of the project, their hierarchical manager also becomes the project manager to avoid any conflicts. As a team, you are together responsible to deliver the project and anyone should take on a maximum of roles (taking into account each person’s expertise) required to deliver the project end-to-end. This model has as advantage a strong ownership for delivery and a good team bonding, but comes also with a number of disadvantages, i.e. it is difficult to take ownership of maintenance after the delivery of a project, it requires a high degree of flexibility of resources to get a different hierarchy and colleagues every X months and it is difficult to free up each team member 100% for each project (due to day-to-day activities, but also due to the fact that not all projects are delivered at the same moment and not all projects require the same amount of resources at every stage of the project).

Ultimately organizational structures and processes all come down to people, i.e. keep people motivated and facilitate collaboration between different persons in the most efficient way possible. Unfortunately, people’s behavior is impossible to capture in a process, slide or Excel file, even though many managers try this in some way. It is important to understand that people evolutionary have an "Us vs. Them" mentality (group favoritism), i.e. put a number of colleagues together, call it a team and you will see in a matter of days, that the group starts to differentiate itself from other groups. While this creates a group spirit and improves the group cooperation and motivation, it also means that cooperation with other groups becomes more difficult and a culture of inter-team blaming is established. Ultimately this leads to silo thinking and silo creation. Think about the typical discussions in a bank of Business vs. IT or projects shifting the blame of delays to other teams that (supposedly) did not deliver critical dependencies. Add to this different physical locations, different employee benefits, different KPIs, outsourcing (which means different teams working for different companies) and your silo forming is institutionalized.

Silo creation is therefore extremely difficult (nearly impossible) to avoid, but the creation of silos and their impact on the organization can be reduced to a minimum. Some practical tips that can help avoid or mitigate this silo thinking in a, organization:

• Goal setting: it is good to set goals for your team, but just as important to set higher (cross-team) goals (typically a common ground can be found in the customer expectations). A goal can be a high level KPI or SLA but can also be a specific deadline. When deadlines are set top-down and defined for specific persons or teams, automatically people will start protecting themselves, i.e. finding reasons why a deadline cannot be met, adding contingency in the calculation of deadlines, blocking the switching of resources to other teams or refusing to support other teams (or team members) with their work…​
  However if objectives are set cross-team, the good of the firm will get priority. Obviously in a top-down organization setting objectives per team helps to structure the work, but it can have - as explained above - negative side-effects.
  The ultimate common goal for all employees are happy customers. As such a continuous monitoring and continuous iteration on the customer’s engagement and satisfaction are key.

• Facilitate employee internal mobility: internal mobility ensures the creation of informal social graphs and very strong interaction points between different teams/departments. This will strongly benefit the cooperation between teams.

• Avoid outsourcing work unless the benefits clearly outweigh the cost. In this digital world, IT is mission-critical for every bank and should therefore be considered as a core competence. Therefore outsourcing IT developments to teams working almost exclusively for you, should be avoided. In this case working with internal resources will ensure that all resources share common goals.

• Hire good people and ensure fun work. Good people working in a pleasant work environment are more likely to put the good of the company first, rather than trying to protect (and improve) their own position.

• Maximize transparency and standardization in HR policies, i.e. contract types, remuneration…​ Differences in HR policy between teams and departments automatically creates a gap and frustration as people tend to feel always disadvantaged (even if it is not justified, it still creates a negative atmosphere).

• Maximize transparency in decision making, i.e. avoid as much as possible top-down imposed decisions, but instead start bottom-up to get the buy-in of all employees in a decision. Furthermore when a decision is made be very transparent and open to employees about why this decision was taken. Employees will understand much better a decision if they understand the rationale behind it.

• Work more Agile with gradual and continuous improvements. This way of working ensures that everyone has a common (short-term) goal of serving the customer. Furthermore via continuous monitoring of these continuous improvements everyone can see the effects of their actions, making this common goal more tangible.

• Work design driven by rapidly creating sample screen mock-ups and prototypes. This ensures that changes are made as tangible as possible and again that the common goal (serving the end customer) is visualized as quickly as possible.

• Avoid "Processes/Procedures" overrun. In order to align multiple teams and persons, the most typical response of a large organisation is the use of "Processes/Procedures". Typically this leads however to less engagement of employees and ultimately to less efficiency and productivity, making it often contra productive. Obviously, a minimum of processes and procedures are essential for a good organization, but the processes and procedures should not become more important than the employees, the customer and the common sense.

• Avoid a too strong hierarchy, i.e. facilitate as much as possible a flat organization, as this will reduce internal politics and conflicts and will facilitate working together to a common firm goal.

In practice this means transforming to a bottom-up organization, where each individual is trusted and decides himself how to maximum contribute to the good of the firm. This is done by fostering a culture of initiative, where ownership and creativity is rewarded and where (human) errors are used as a learning and improvement opportunity (how can this error be avoided in the future), rather than a crusade to find the person to blame. Additionally a strong company culture (identity) should be built, which supersedes the culture and practices of individual teams.

Let’s all work together to tear down those sils !