Untangling Organizational Dependencies
Or learning to collaborate after you’ve adopted product-based funding
Or learning to collaborate after you’ve adopted product-based funding
I’ve been thinking about a problem that may be a niche or less spoken about at the very least. The problem is how organizations learn to collaborate once the teams and departments move to product-based funding. They no longer have the project to drive priority and alignment caused by the funding and they typically have fewer project managers to pull the threads together.
As part of adopting product-based funding, organizations often take the opportunity to delay their setup as a way of further driving out ‘simplification’ and reducing the number of layers and managers between the team and the CEO.
This often serves as a proxy for reducing bureaucracy and providing teams with more empowerment and autonomy — however, the reality is that unless the organization changes its culture/behaviors and language many of the pre-existing challenges will remain with simply far less people in the middle to deal with the bureaucracy.
I was recently inspired on this topic by the incredible Jim Benson, who shared a talk on the NYC Complexity lounge meetup and Jim’s recent post/video is highly recommended.
Where did all the middle managers go?
Reducing the number of middle managers (including project managers) can put a significant strain on teams who have previously had a layer or two between them and the broader organization.
Whilst the idea of less middle management can be appealing to some, reducing the layers without fixing the systematic issues becomes quite the double-edged sword:
it can offer a layer of protection between those doing the work and those communicating it to others (status updates)
it can make things harder to align between the organization as those doing the work aren’t able to align with the wider organization due to organizational silos and middle management in the way
If managers serve as a mechanism to communicate with more senior management, then often a project manager serves as a mechanism to collaborate and align across an organization (albeit from a delivery-focused perspective). This mechanism can be vital when the organization is funding projects and relies upon budgets to coordinate and align the work. Money drives the work in these cases.
In the case where you’re funding products and you haven’t addressed these systemic dependencies, you are likely to run into trouble. You effectively end up with people using their own capacity to fund the work that they want to do, rather than what is best for the organization.
Ironically moving to product funding allows for a major simplification of funding and capacity management, whilst at the same time exacerbating your dependencies to an unheard-of level, because you have lost your ‘funding carrot/stick’. Previously money was the way to get work done, now you must collaborate and align to common goals.
This requires quite a distinct set of skills and approaches to ensure planning, prioritizing and alignment are all working like a well-oiled machine. This is especially true in heavily regulated organizations where regulators have strict dates and people are obligated to deliver to stay in business etc.. You can tell when people use terms like committed or mandatory.
Moving to product funding also doesn’t address the ongoing dependencies you have in your system of work. If you adopt product funding, you should really think about your flow of work in terms of value streams and value networks, so that you know who to work with and how to engage and that is just to keep things working.
There’s a lot to do to improve the flow of work and eliminate dependencies by adapting your architecture and approach to engineering. If you don’t address this, you risk facing a lack of incentive from the producing team to the consuming team.
Surely OKRs solve all
Even if you introduce a strategic alignment mechanism like OKRs, they take time to embed, and highly likely your organization will not realize how to use them effectively if they are only being implemented because they think that is what they are supposed to do.
Let’s take a hypothetical large complex organization with multiple revenue-generating departments or divisions and shared service departments or functions. Each department has started using OKRs, so they all implement their own OKRs for their own portfolios. This creates many conflicting priorities and ends up bubbling many OKRs to the common layer of the organization e.g. the board of directors.
What happens is each department is running its own investments and strategies and they are trying to justify their investments in whatever it is they are doing. This part is often caused by a left-over legacy enterprise architecture and portfolio management process that drives long-term thinking over short-term outcomes before true product management capabilities have been embedded in the organization.
What they haven’t done is think about the goals their sibling departments are focusing on (especially the revenue-generating ones) so you end up with competing priorities at the top. e.g. a finance department to generate its quarterly and annual reporting as close to the end of the period as possible, whilst the sales organization is trying to generate new revenues from new markets/segments.
What happens is that both departments are trying to optimize for their own needs. Both departments have dependencies on each other. The sales department cannot record its revenues until the new products have a pricing model and a set of accounts in the financial system. The finance department cannot speed up its financial reporting unless the sales team all focuses on improving the data quality of their upstream systems and generating the feeds more quickly so that the report can be generated on time.
Both groups are dependent on each other, both groups haven’t been able to align on a common goal / OKR that they both agree on for the quarter and now both groups are unable to deliver on their outcomes because instead of aligning, they have locally optimized and are now blaming each other at the quarterly review where both departments are walking through their OKRs and their lack of results.
With the organization having adopted product-based funding, many of the people who previously ‘got things done’ across the organization are no longer there. The responsibility for coordination falls onto the teams themselves who have never had to do this before as they previously relied on the project managers to do all of that.
It’s not all bad
The moral of the story isn’t to single organizations out, but if you over-emphasis locally on your system of work without thinking about the wider good for the company/organization you risk creating bottlenecks that could have been avoided.
There are ways of solving this type of problem, many of them especially in the short term require significant focus and overhead to coordinate and align teams on common goals and not just on the goal but the actual work itself, including testing/interfaces and releases as well.
In situations where you have historically had a lot of project managers involved to get things done, moving to product funding will only make things more difficult from a coordination perspective and put additional strain on the teams themselves.
Whilst empowering teams is great, they cannot effectively collaborate across the organization every time a piece of work is required, especially when the teams aren’t aligned into a value stream with predictable communication channels, APIs, contract testing, etc.
A way out
If you have regular need of other teams, it may make sense to consider working with them to agree on a ring-fenced amount of capacity for a period of time so that they can continue to ensure they can help you with dependencies, just be sure to focus on reducing the fixed capacity over time by having teams build self-service capabilities so that you don’t continually need to rely on them for you to deliver your outcomes.
A more radical approach is to allow your teams to self-organize and interface with other teams regardless of the department they are in. Think of this as a value network, where each team in the network establishes a Team API for how others should interface with your team (as suggested by Team Topologies). Give others a way to know how to interface with your team and for what purposes. Once you mature your team API, over time other teams will start to be able to interface with your systems more independently and you can start to build solutions that allow for them to interface with your system without constantly having to get your team to change and prioritize work on their behalf.
2 laws to consider
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
— Melvin E. Conway
Adding manpower to a late software project makes it later.
— Fred Brooks
Extract from Wikipedia: Due to combinatorial explosion, the number of different communication channels increases rapidly with the number of people. Everyone working on the same task needs to keep in sync, so as more people are added they spend more time trying to find out what everyone else is doing.
There are many approaches to think about in this problem space but starting with a value stream mapping exercise is an effective way to visualize the system and all its constituent parts. Building a shared understanding between teams involved is required to learn who is involved and what each other thinks each part of the system does.
Once you have a shared understanding then you can start to think about how and where you want to start experimenting with tweaks.
If you are going through an ‘Agile Transformation’ (aka organization redesign) and not considering these points you will very quickly run into trouble when you need other teams to help contribute to your outcomes.