Give Your Engineering Leads the Budget. Get Out of the Way.

True engineering pods are built not top down but bottom up. At least, from the Engineering leadership at each pod building up, along with showing their teams the direction.

When organisations build central platform or DevOps teams, they are in essence doing the opposite. A pod that needs to scale, fights with an Ops team. It fights when it needs a certain service that is centrally orchestrating between three others, for inclusion of a new key to better understand their product flow.

What I suggest is something different.

Each pod’s Engineering gets a fixed budget; a number arrived at based on leadership’s assessment of a fairly long enough window in the past.

Let us assume, it is $2k/month for the payments pod at Acme Corp. Now, the quarterly budget allocation is $6k, all under the control of Payments pod to work with, rather than Devops teams enjoying authority at each turn.

Now, Q1, Payments Engineering lead decides he needs to find better ways to handle the pod’s services and works with the team to take time out to optimise the services, deployment strategies, and may be some product workflows as part of their quarter plan.

Assessing the quarter spends on this pod, we see that they have burned only $3000 this quarter, much less than their budget.

A few things happen in this case.

First. Has the pod achieved their planned quarter target aligned with the larger AOP? Let us say, their north star for the quarter was 25% merchants signing up to transact within the first 5 days. And the business metrics dashboard says, they have reached 25%. Then, the budget surplus they have achieved, is theirs entirely.

Want to carry it over to the next quarter to experiment further? Or sponsor a product workflow the PM wants to, towards increasing a certain metric or improving the workflow? Or, invest in different infrastructure products for better visibility for Engineers in the pod so late night random pages are a thing of the past? Or invest in the Engineers themselves, by sponsoring a good one towards a course or books for all if that is your flavour as an Engineering leader? Knock yourself out.

Second case. The pod achieved only 20% conversion. That’s 80% of business outcome achieved. Hmm, not great. But they did save on their costs significantly. So, what happens? They still carry over the 80% of their savings; $2400 in this case to the next quarter. How do you want to spend it? Your take as earlier as the leader of the pod.

Breakevens are easy to figure. A pod that hits target and breaks even keeps their baseline intact — no penalty, no surplus.

Assume that the pod achieved 20% instead of their target of 25% and did not overshoot their budget. The pod then starts a little lower on the budget the quarter next. A minor penalty if one may, to keep the incentive aligned with outcomes.

Overshoots are a leadership call, but with a buffered historical baseline, they should be the exception rather than the design case.

Where I see such a framework is it puts Engineering leaders at a place where they own it from the ground up and have skin in the game, rather than make them helpless middle managers who get the short end of the stick at both ends. This situation is precisely what kills drive in experienced devs who get to the level of PEs or EMs to work on improvements and put their skin in the game.

This is a general framework and leadership above can tweak to better align it for autonomy and/or business outcomes. A long hard look at it tells a few things — this needs a change in the larger ethos and culture of the organisation. A classic case of who bells the cat, as it were.