Goal of this stage: create transparency around tech overhead that doesn’t necessarily align to business outcomes

Given the way we’ve structured these decider groups, it won’t necessarily be the case that the technical owners of each of your distinct software systems is represented in any of them. Nonetheless, each of these technical owners have various tech-driven initiatives they need to get done. Some of them are tech debt to clean up. Some of them are the necessary upgrades and other migrations that just have to happen with living, breathing software. Some of them address scalability thresholds that their systems have crossed because your business have been so wildly successful.

Most likely, none of these initiatives will fit nicely into any of your business-oriented groups. It’s very likely that nobody outside that engineering team will understand what they are or how to advocate for them. But they do still need to get done. They’re not going away. So, you really only have three choices in addressing them:

1) pretend they don’t exist and eventually go out of business in a supernova of system failure drama 2) give your system owners a fixed slush fund of their own resource, unallocated to this strategic process, that they can use as they see fit 3) gather their projects into this process and have them advocate for them alongside everything else just like any other project

Option 1 is obviously not a good option, even though it is the one that most businesses slouch into anyway, unless forced to do otherwise. Option 2 definitely works, but it isn’t, personally, my first choice because it isn’t transparent enough and tends to breed mistrust between “the business” and the engineering team. Option 3 is a delightful choice, in my opinion, though it does tend to be frustrating and stressful for those system owners and they will likely need help in navigating it. What’s most important, above all, is that you consistently stick to one or the other of these approaches, and that every team does it the same way.

To persue Option 3, have each system owner identify and prioritize tech debt projects to feed into the process alongside everyone else, as if they were their own group. Alternatively, designate one, single, existing business aligned group that is “theirs” and have that group prioritize and advocate for their projects. Either works pretty well, depending on the particulars and personalities involved.

The persue Option 2, simply decide what you want the percentage allocation to be, and hold out that allocation from that group’s capacity in the last step of this process. Boom, you’re done.