All engineering teams I know have more work to do than they have time to complete. This is normal and healthy. The team prioritises their work so they only do the most important things. The team creates a backlog of work for their product, sorted by priority.
Within an inner source community, several teams contribute to the same product. Each team has their own backlog of work for that product, sorted by their own priority. Each team also reserves some time for cross-team collaboration and review – the cost of doing inner source.
Unpopular Work
The backlogs of all engineering teams I know includes work I’d call “unpopular”. Security updates to your dependencies to reduce risk. Refactoring to make future changes easier. Improving test coverage to reduce the risk of introducing bugs. Making the build pipeline faster to save time every release.
This work is important, and valued by all well-informed stakeholders. But it has no short-term impact for the customers of your product – a feature they’ve requested would be more popular. Maybe this work would be best described as indirect work. It’s not directly visible to your customers, but it’s critical to reduce risk or for long-term success.
The “When” Problem
Unpopular work is often neglected. If not urgent, it’s easy to postpone. If reducing risk, it’s easy to hope for the best. If saving cost, its easy to run over budget. This is the question of “when” – when does the unpopular work ever actually get done?
All the high-performing engineering teams I know recognise this challenge, and have a strategy to prioritise unpopular but important work correctly.
The “Who” Problem
All inner source product communities share this challenge – ensuring unpopular but important work gets done. But these communities have an additional choice: who does the unpopular work? When several teams can do it, which team should do it?
Even with only two teams this can resemble a game of chicken:
The game of chicken models two drivers, both headed for a single-lane bridge from opposite directions. The first to swerve away yields the bridge to the other. If neither swerves, the result is a costly deadlock in the middle of the bridge, or a head-on collision. The best thing for each driver is to stay straight while the other swerves (the other is the “chicken”). A crash is the worst outcome for both drivers. Each driver, in attempting to secure their best outcome, risks the worst.
Both teams know the unpopular work is important, but would prefer the other team to do it. The best outcome for each team is to do only popular work, while the other team does all the unpopular work. No-one doing the unpopular work is the worst outcome for both teams. Each team, in attempting to secure their best outcome, risks the worst.
I haven’t played “chicken” since I was a teenager messing about with radio controlled cars with my friends. For good reason – its reckless and irresponsible. A bad outcome is likely. There are better ways to have fun. Thankfully, there are also better ways than “chicken” to manage unpopular work in inner source.
Maintaining Team
Most inner source products have a “maintaining team” – a team that owns and is responsible for the product or service. For products in stage 1 or 2 of the inner source pyramid this is the team which all the maintainers are members of.
This solves the “who?” problem – the maintaining team does the unpopular work. This team must solve the “when?” problem themselves, which usually requires pre-agreed dedicated time or sprints.
- Dedicated time. The maintaining team agrees and reserves a fixed amount of their sprint budget for unpopular work. Just measuring and reviewing the amount of unpopular work completed can make a big difference.
- Dedicated sprints. The maintaining team reserves 1 in every 5 sprints for unpopular work.
Sponsorship
An inner source community can share unpopular work across teams. Each team can “sponsor” different areas of unpopular work. For example:
- A new team on-boarding to the product sponsors test improvements, refactoring & simple dependency upgrades. This benefits them as a contribution learning exercise – a form of training. It also benefits the whole community.
- One team agrees to own the unpopular work of dependency upgrades, if another team owns a cost saving project.
Listen to a Principal Product Manager describe unpopular work priorisation within our inner sourced Global Betting Platform.
Virtual Maintainers Team
Products in stage 3 of the inner source pyramid have maintainers in several teams. This group of maintainers do spend time working together as a virtual team or working group.
This virtual team can prioritise and execute unpopular work directly. These maintainers are short on time, especially time together. Usually they work directly together only on the most challenging bits of unpopular work, complex changes that require collaboration and alignment. Once they’ve resolved the complexity, the remaining simpler changes are often sponsored into each of their teams.
Strategic Intervention
Some unpopular work projects are significant long-term strategic investments that no individual team can justify. It feels wrong to call these projects “unpopular” – they’re often the most important projects of all, and ones with widespread support. But they’re unpopular in the sense that no team does them, because they’re too big and their return on investment is too long-term.
These projects require a strategic intervention. A senior leader must sponsor the project, and fund and mobilise a team to do it. An inner source community is already setup to welcome an additional contributing team. The entire purpose of this new team is to do the “unpopular” project.
by: Rob Tuley
in:
tags: WoW Pull Requests
category: Academy