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.
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.