Close overlay our DNA
Call us on
+44 (0) 207 125 0351
Email at
This thought leadership article is based on our experience supporting many leading global Asset Managers in their new ‘ways of working’ to eliminate waste, reduce handoffs and become more responsive and relevant to their customers.
Let us be pragmatic on what a ‘Product’ is in the context of an Asset Manager – what is the trigger?
Operating in a product-mode is classically defined as loosely coupled, autonomous teams ‘vertically’ aligned with the company’s products. In the context of an Asset Manager, a typical product is a ‘Fund’ in an asset class. It is not viable to align teams vertically around ‘funds’ or ‘asset classes’.
The traditional and easiest organisation design is a functional orientation or ‘activity-oriented pool’, e.g. BA Team, Dev Team, Testing Team, Change Team, Data Team etc. In the activity-oriented model, Project Management becomes a pivotal function to act as the glue in bringing people together and delivering change. Projects are staffed from a pool of talent whose members are considered fungible within lines of specialisation. Usually, a Project Team’s job is to build or enhance a system or application and move on.
Since most of the measures are focused on project delivery, no real consideration is given to systems and applications. Over time, these systems and applications become unrecognisable and complex with customisation, garnering huge technical debt and unwanted or unused features. This gives rise to increased architecture complexity, unstable systems, increased rework, multiple handoffs and unacceptable cycle time; this leads to frustration between teams and the business and is often the key trigger for a more ‘Product-aligned’ agile delivery approach
In the context of Asset Managers, the ‘Product’ is synonymous with business capabilities — common services, features and functionality used in many or all of the company’s business products e.g. Distribution, Risk/Investment management, Data management, Customer reporting, Asset administration, Transaction processing, Settlement, Payments etc.
Initiatives like a new Product launch, addition of a new Asset Type, Operating Model Transformation, new Regulatory requirements etc. require Asset Managers to add or change features in multiple capability/product areas of the organisation. These initiatives need cross-team coordination to deliver value. The coordination effort involved in them is what we call Programmes. If not managed effectively, the opportunity cost is missed revenue, unsatisfied customers and wasted team capacity.
Many Asset Managers have created capability-aligned Product teams. This organisational structure is similar to the Spotify model where squads and tribes are aligned to the product architecture. It suits extremely well in a micro-service based modern tech ecosystem, where API culture can minimise backlog-coupling and reduce data dependencies. But for most of the Asset Managers that we have come across, their current architecture is complex and not modular – they are in a journey towards modernising their architecture by transitioning their platforms to cloud. API-based mindset and platform thinking is not organic or natural to them. Any new transversal change or a new product launch, where it requires multiple capabilities/products, need to have a different and adaptive approach towards ‘programme management’
Holley Holland is often brought into an organisation to help them improve their operating model, which includes programmes, data strategy and other transversal initiatives.
We start with a retrospection. Here are a few of the retrospection themes;
The flow of value to the customer vs Product alignment
Local optimisation by the product delivery teams without considering the end-to-end operational value-stream flow.
Lack of visibility of programme information
There is no consolidated programme status view. The progress updates are focused on individual product delivery teams instead of an overall reflection of the working solution addressing the customer outcomes. The teams are not aware of their involvement or impact on the programme.
Risk management
This is left as an implicit task assumed to be managed within the delivery teams, but not as an explicit programme-level effort. This means that there are many surprises along the way which impact the delivery date.
Dependencies between teams
Lack of cross-team collaboration leads to tensions forming between the delivery teams, which damages the working environment and impacts the morale of both the individuals and the team.
Communication
The programme leadership team do not change their communication style to suit the context and situation. There is often no shared understanding of the programme goals and outcomes. It is assumed that each product team has the information needed to deliver their piece of work!
Overall team motivation and accountability are compromised due to the problems above.
The observations above describe what we see to be common challenges for product-mode organisations when responding to operational value-stream based demand with a requirement for cross-team coordination in a programme-like situation.
The remaining points of view outline strategies, practices and principles that we have used when working with organisations to address some of these challenges;
Structured and proper discovery
Shared understanding and early involvement
A programme canvas workshop will help to drive a shared understanding of roles and responsibilities, goals, purpose, and rules and activities of the programme.
Red Team for the Programme
Red teaming techniques help to identify the riskiest assumptions in the programme and the approach in order to validate them and learn. Red Teaming is a more structured and lean approach to programme risk retrospection and reflection.
Change in the leadership style
Programme leaders need to adapt their leadership style to the demands of the initiative. It is usually a disaster if the Programme Manager operates in command and control of the Product-based teams. As an example, the situational leadership model, which involves more time in clarifying, empowering and defining is a wise choice.
Managing backlog-coupling dependencies
Dependencies between teams, known as backlog-coupling, are common in programme delivery as multiple teams will be responsible for delivering different discrete parts of the solution. A good practice for proactively managing these dependencies is to frontload the programme delivery with activities intended to decouple individual team backlogs, enabling teams to deliver more autonomously.
For example, to reduce the backlog-coupling between the product teams, the discovery team might decide to spend its first few iterations; MVP 1, teaming around building a walking-skeleton. This enables future programme progress updates to focus on the evolution of the walking-skeleton as more fidelity and depth of scope is added by the product teams.
Strong communication strategy
Due to this required overhead of communication in programmes, programme leadership should look to create a strong communication strategy with touchpoints that satisfy the needs of each stakeholder group
Visible Programme board
In addition to a programme Jira board, there could be a virtual Programme wall in a Confluence page which radiates – user journey maps, story maps, retro themes and MVPs. Moreover, virtual programme walls can help prompt questions from other people in the company by allowing them to consume information quickly without needing to schedule time with anyone.
Clarity on responsibilities of the roles
The discipline of programme management is crucial to ensuring success when any transversal and operational value stream initiative involves the orchestration and coordination of multiple agile teams to deliver value. However, the actual role definition and responsibilities will depend on the organisational context and programme complexity.
One of the outcomes of the discovery session is bringing a shared understanding of roles and responsibility. For example, the need to deliver.
We shouldn’t be dogmatic about a model/pattern/methodology. Instead, define key guiding principles for a context. Once we understand the initiative is transversal and aligned to an operational value stream, it becomes clear that an adaption in the operating model is required to deliver value to the customer. Even where we have listed several strategies, practices and principles that can put the programme on the path to success, there is no silver bullet for that success. Regardless of the mechanisms you choose, make sure you put in place a feedback loop and continuous retrospection with the programme constituents, to learn and adapt whenever necessary.
Prasad Prabhakaran has more than 20 years of experience working with large and medium multinational enterprises and product companies. He has hands-on experience in building Digital Products and helping enterprises in their journey towards business agility. This has led him to becoming a trusted partner and coach to CXOs of Enterprises and helping Boards of some of the leading firms rethink about how the operate via Ways of Working.
Prasad is also associated with many international conferences as a speaker and program organiser such as Agile UK, Agile India, Discuss Agile, and Digital Conclave. As recognition of his contribution to this community, Prasad was honoured with ‘Agile Leader’ of the Year award in 2016.
