Let's talk about (one aspect of) throughput accounting (and bear in mind that everything I'm about to discuss applies to software teams as well). A friend of mine has gotten the notion into his head that the insurance companies should go into the car-repair business. His thinking is that when he goes into a repair shop, the shop is willing to do the job for half what they're charging the insurance company. He posits that if insurance companies did their own repairs, they could do it for half of what they're paying now (and pass the savings on to us ⌠yeah, right đ). Let's examine that premise.
First, I don't buy the implied premise that the repair shop is raking in the dough by gouging the insurance companies. Most barely get by.
How, then, can that repair shop afford to give us a 50% discount? They can save some money in direct paymentâno time spent on paperwork and insurance billingâbut that's minimal in our automated world, nowhere near enough to justify the huge discount.
The answer lies in excess capacity. A repair shop operating at 100% capacity must acquire customers at exactly the rate at which it can complete the work. That never happens. There's simply no way to know who will walk in the door today. There are times when you have no work at all; there are times when you're turning work (and money) away. (Backlogs are not viable in this contextâpeople will go to another shop if you're busy.) The Lean folks call this "variability."
You must plan with variability in mind. The goal is not to be busy all the time, but to have a smooth, predictable, and reasonable revenue stream, even when the workload varies. Businesses need a smooth workflow to plan effectively. To achieve a smooth flow, you need to build unused/excess capacity (slack time) into your schedule to accommodate unpredictable busy periods. Don Reinertsen, in his book "Principles of Product Development Flow," suggests about 30%.
So, let's get back to that discount. The cost of using some of your excess capacity to do work is $0.00. The rent and other expenses, including your salary, are paid. If you didn't take on the extra work, you'd be fine. Put another way, that excess capacity has already been paid for, whether or not you use it. Consequently, any money you bring in during âexcessâ time is pure profit. Working at half your rate? Still pure profit since it costs you nothing.
Of course, there is some risk here. You don't want to be using excess capacity to the point where there's no longer any excess. You must be able to take full-paying work that might walk in the door, so this strategy makes sense only for small jobs with a definite end, and you still want to leave some slack in your schedule to handle the inevitable. There's also a balancing act. You can't create slack time by charging so much that you lose customers. That's not slack, it's failure. "Excess" is the key word.
Getting back to my friend's fallacy, the repair shop cannot do all its work at half price, whether or not the insurance company owns it. Once the shop has covered its expenses and necessary profit, however, everything extra is gravy.
Finally, I'll remind you that everything I just said applies to software teams. Our car-repair shop's economics are identical to software-team economics.
Iâve thought about this overnight and would like to suggest the addition of one word to your assertion about flow-through accounting applying to software teams â âsuccessfulâ. This applies to successful software teams.
Netflix springs to mind as an example of a successful software engineering team, but we could also imagine a startup with sufficient ârunwayâ and effective methods and practices.
Iâm leaning heavily on the word âimagineâ because in my experience itâs much more likely that any slack time in the financial model was inserted to paper-over the uncertainty about what can be delivered when, and assurances given about the âdelivery scheduleâ.
In a non-trivial number of organizations, estimates are religious canon and âagileâ is a meeting in which everyone recites yesterdayâs to-do list and then shares todayâs. (Yes, I know, this âshouldnâtâ be, but neither should war or murder or âsnack food productsâ.)
I suspect that, statistically, a software engineer is more likely to perceive âslackâ exclusively as the app they use to explain why they âcanât talk right nowâ because they need to âget their pull requests into the cadence release by Tuesdayâ.
Letâs assume that the average software engineer is âabove averageâ (winking smiley-face emoji). They build slack into the expectations they set. That slack is consumed by exigencies and emergent complexity.
The cost accounting doesnât include the cortisol, insulin resistance, and suppressed expletives that pile up inside the engineering team members.
So: Yes. Agreed. Thatâs insightful and interesting. But thereâs more to be accounted for, and it doesnât all flow through. We need another revolution, or reinforcements for the last one.