Pork barrel software planning

In the US Congress, Pork Barrel spending happens when a bill (proposal for a law), on its path to collecting votes to become law, gets bloated with a bit of "pork". The "pork" in this case is national funding for local, specialized projects.

In the dimly lit halls of Congress, a bill's sponsor will pad "pork," essentially pet projects for specific Congressmen, to win over those same Congressmen's votes. The sponsor of the bill is happy that it passes, the "pork" padder is happy their pet project is finally funded, and the tax payer, ultimately paying, is none the wiser when they neglect to read page 6,070 of 80,123 page bill which allocates funding for a "bridge to nowhere". 

In the corporate software development world, we see the same pattern, which I am dubbing "pork barrel software planning". In this case, a company's top leadership decide to do a project, but they have to "bribe" lower managers and directors to get it done.

In tech companies, especially "flat organizations", power sits in the lower rungs of the corporate ladder. As mid-level managers hold some power, as well as their own project desires. When a company's top leadership wants to drive a new strategic project, top leadership has to convince all the mid-level managers. This power dynamic between top leadership, and mid-level managers leads to "pork barrel software development". 

Middle managers end up adding their pet-projects into the top leadership level strategic initiative. For example, in my previous role in a music company, top level leadership pushed for adding in podcasts to more of the platform, a massive project spanning multiple teams, dubbed "Audio Charge". The search team, needs to enable search for podcasts to do their piece of "Audio Charge".

The search mid-level managers has to get their engineers to write the code to add in Podcasts. And the engineers, often have pet-projects they want to see invested in, perhaps "refactor the ingestion infrastructure to to make adding new types of audio easier". All of a sudden, this engineer's pet project, fix tech-debt idea is "pork" being added to the "Audio Charge" project. It's not stricly necessary, but as mid-level managers and engineers want it, they add it into their planned "Audio Charge" work.

Mid-level managers, in a game of telephone up the ranks of management, convince the top leadership that this "pork" is necessary. Perhaps they argue it is "a key strategic underpinning that will allow all of 'Audio Charge' to move faster, but it just requires a bit more investment. 

For top level leadership, now "Audio Charge" is taking longer than they hoped, and is more expensive, as it has been bloated by mid-level managers' pork. A game gets played, where if mid-level manager can re-brand/re-tag work as a piece of the top level leadership project, mid-level managers are allowed to allocated engineering time to get it done.  So we end up with "pork barrel" software planning , where managers pad estimates to allow for resourcing, and allow for pet projects to make the cut-line in yearly investments. 

"Pork barrel software planning" can be a symptom of a leadership team out of touch with the state of software systems, who are pushing for too many new features, and not enough investment into infrastructure.