Dealing with teams with competing priorities and needs
An organizational challenge explained
I’m so fortunate to learn about organizational challenges technical leaders are facing in their day-to-day job and brainstorm with them which are the options to untangle their challenge.
Today, I’m sharing with you a similar organizational challenge that I faced in the past, and which options did we explored to overcome the high-stake challenge.
Business context
This company is a Fintech that operates in the USA. It is a B2B2C in which helps businesses to consolidate the money of their clients from multiple banks into one account.
I didn’t know this, but it looks like the banking system in the USA is composed of +4000 banks. Contrary to the EU (correct me if I’m wrong), it looks like the USA doesn’t have a regulation, like the PSD2, which would make the integration with multiple banks easier (supposedly).
Therefore, when you need to integrate to a bank, you need to create a specific integration to each bank.
Which it just makes me wonder, does exist any product that those that for you already? Like a bank integration API product or something? 🤷
Business challenge
For each new client that we onboard, and we don’t have an integration with their bank, we need to create the integration for that bank.
The challenge is the next.
Integrating with a new bank requires a huge dedication by the Account Team for a couple of weeks.
The technical debt is increasing. Therefore, multiple challenges arise, like maintaining past integrations cost increases, due to:
Adding new features to previous integrations become more costly.
Solve bank specific failures.
Opening new accounts (onboarding new clients) become a bottleneck due to the Account Team.
The first fix, split into two teams
The Account Team has the responsibilities of opening new accounts, onboarding new clients (this is manual work with the client), integrating with the bank, …
It has huge responsibilities, a lot of moving peaces and stakeholders.
For one side, talking to the client and being sure they have a good experience.
On the other side, make all the connections, and be sure the system works, etc.
That’s why they thought about splitting the team and assigning more narrowed responsibilities.
Account Opening Team.
Responsible for onboarding new clients, they're having a smooth experience.
Success metric: Clients onboarded per month.
Account Integration Team.
Responsible for the technical aspect, being sure the accounts are operative.
Success metric. Lead time for accounts ready to be operated.
It looks like a great solution at first, but if we look closer at the flow of change using Team Topologies nomenclature, we identify the next scenario.
Although the intention was to provide autonomy to teams, we find that they keep a strong collaboration to reach their goals. They are strong co-dependent.
The problem
It is common that after splitting a team into two, for some time they will be collaborating, but if the collaboration stays for too long, there is a problem.
The initial reason of splitting team was to have dedicated teams with dedicated objectives and narrowed responsibilities. When we look closer, we can identify that:
They are co-dependent.
Account Opening Team isn’t autonomous to serve their clients. They rely on Account Integration Team to serve their clients.The success metrics aren’t set for success.
Account Opening Team needs strong coordination and backlog prioritization on Account Integration Team to meet their business objectives.One has more business visibility compared to the other.
Account Opening Team is exposed to clients, their needs, and can be easily tracked. It is a team with high business exposure.
Clients onboarded per month == 💰💰💰.
On the other side, integration team can be seen as an IT operation, a cost of doing business.Now the problem is moved to management because now it is a coordination/collaboration problem. Exposing less the developers to the problem, and creating a top-down situation.
Now, the team cannot improve the situation by themselves. They require the management to care and prioritize the concerns they identify.
Let’s add a common business goal to the equation.
We want to grow our customer base by Y.
This business goal can be part of a strategy, and probably it will be listed as part of an OKR. That business goal will be owned by Account Opening Team. It will get prioritized, and then Account Opening Team, in order to achieve this business objective, will gain even more influence over Account Integration Team.
All of a sudden, we created a damaging dynamic:
Account Integration Team become a feature factory.
Account Opening Team gain a lot of business authority but without autonomy.
The competing metrics makes that:
Account Opening Team keeps asking for more integrations.
Account Integration Team is:
Understaffed
The lead time to integrate keeps growing.
Technical debt keeps growing.
Resolving incidents becomes stressful and frequent.
There is no time for learning, people know that this isn’t sustainable for the long term, but there is no indicator that this will improve.
Initiatives that aim to improve the situation fail because they don’t get prioritized enough, rolling back to previous dynamics. Creating inertia to try to improve the situation in the future.
“We adopt a defensive strategy, let’s keep the lights on.”
“I don’t see this improving, I might start looking for a new job.”
An alternative
The organization challenge is hard. It is a problem that requires developers to do custom integrations every time, and the nuances between providers make it hard to automate.
Let’s redefine the business challenge:
For each new client that we onboard, and we don’t have an integration with their bank, we need to create the integration for that bank.
Creating and maintaining the integrations for customers smoothly is key to:
Have a smooth customer onboarding.
Don’t allow our competitors to have more integrations than us.
Keep our systems up and functional.
Analysis
Based on past behavior, it is easier to create a team with specific objective rather than negotiate priorities within the team. Even though that implies more collaboration between teams.
Account Integrations Team is unable to prioritize technical needs over business goals, even though that’s damaging for the company in the mid-long term.
Keep onboarding customers is mandatory.
The system has high technical debt.
Any new integration requires almost full dedication of the Account Integration Team for a couple of weeks.
It means that they can integrate with, best case scenario, ~24 banks per year.
Direction
Enhance team autonomy by removing/reducing team dependencies.
We will create an isolated account integration platform with the goal of creating a self-served integration for Account Opening Team. It is important to build an internal product first, before aiming to expose it to the end client.
Account Integration Team and Account Opening Team will keep working as usual until we involve them into the new approach.
The new approach should reduce the team’s pain considerably to overcome the inertia to change.
The new approach needs to address Account Opening Team needs first, and Account Integration Team second, but they have to be addressed.
Coherent actions
1. Isolate an Account Integration Platform
Keep the lights on by keeping the same ways of working and collaboration between Account Opening Team and Account Integration Team.
We create an Account Integration Platform Team with the mission of creating a self-served account opening, where possible, for Account Opening Team.
Bring key 1-2 Account Integration Team members, and fill up to 4 people in the platform team. We want the team to be small and isolated because:
Prevent becoming an integration team again.
Boost high collaboration, high knowledge sharing between team members.
Set the new ways of working without falling back to old patterns.
Not be a business critical team (yet).
Easy to rollback in case it doesn’t work.
2. Define a self-served experience for Account Opening Team
Create an internal product, or XaaS, to help Account Opening Team to self-serve customers that we don’t have an integration yet. This can be in the form of internal SDK or NoCode solution.
3. Collaborate with Account Integration Team to understand their pains and onboard them on the new approach before it is too late
We want to keep the Account Integration Team involved as much as possible and try the new approach on low risk clients as early as possible, but not too early that they have a bad experience.
4. Merge the platform to the Account Integration Team
When the new approach is functional enough, consider merging back the Account Integration Team and Platform. The best team configuration will be the outcome of the collaboration between the three teams, with the objective of reducing the co-dependency as much as possible.
Summary
When I find organization dynamics that keep becoming worse and worse, I search for those dynamics that will allow me to put an effort to overcome it.
Instead of trying to introduce the improvements as part of the normal flow, I look for an alternative to set the right foundations for the initiative to succeed. Then integrate that initiative earlier as possible with early adopters within the organization before it is too late and people don’t feel ownership over the initiative.
Isolating a team from the business as usual helps you gain novelty, and stop damaging behavior. You will create new ones, be careful before it is too late. You don’t want to create an us vs. them culture.
The approach of serving internal customers first works better because you can access them, and, usually, they have more patience when you fail. They help you learn from those mistakes. If we aim to solve it for the end client/customer, then you need to involve way more stakeholders, making the initiative riskier, and the feedback loop longer.
The reason of merging back the Account Integration Platform team to the Account Integration Team is because the purpose is to set a new way of working. After that, you want to reduce collaboration. Because the Platform team size is constrained to up to 4, it shouldn’t be a huge problem merging back.
But I would keep open to any better option after all the learnings that this initiative had.