Sometimes you encounter a striking figure of speech, comparison or just a metaphor that illustrates some concept in a much better way than anything you knew until now. It's so good you can't let it get unnoticed. In my case, it happened e.g. when I've learned to think about architects as "navigators". Or quite recently, while I was reading a very decent book by Michael Lopp - "The Art of Leadership: Small Things, Done Well".
Speaking about the latter: my epiphany moment happened during chapter IV, entirely dedicated to the author's actionable advice for engineering leaders. The concluding one was about a reasonable alternative to micro-management: Lopp calls it ... "tasting the soup". And I think it's brilliant and 100% spot-on.
A culinary parable
Tasting the soup - what does it mean?
Imagine a professional chef. A chief boss-cook. A reigning monarch of the kitchen (e.g. in a top-notch, highly reputed, Michelin-starred restaurant). (S)he is the person accountable for the quality of the holistic culinary experience here. It's his(/her) reputation at stake if customers are dissatisfied (for any reason). But still, it doesn't mean (s)he does all the job him(/her)self (to guarantee a suitable level of quality) - quite the opposite. There's the talented, hand-picked crew doing all the "dirty" work, while the chef-in-charge:
- tastes
- probes
- verifies
It's not that (s)he cares only about the final outcome - the 100% ready dish. (S)he engages at all the various stages (of meal preparation): by inspecting raw materials, half-cooked ingredients, nearly ready products about to get the final touch. What's more - the soup is "multi-dimensional" - it has several equally important aspects (to assess separately): consistency, smell, color, temperature, sweetness, bitterness, spiciness, etc.
Needless to say - the chef can't (& shouldn't) be everywhere, all the time. (S)he can't assist every elementary activity - which is good and ... desirable. One should not judge the effect by the activities performed (which are - in many cases - meaningful "implementation" details or just elements of a highly-individualized style) but by the outcomes and how they match expectations (stated beforehand).
How does XP work
That's why (s)he restrains her(/him)self to taste and probe - it's sufficient because of past, practical experience. Precisely because of her/his experience, (s)he knows what to expect, whether the chosen direction is correct, whether there's a chance the final product will be edible & satisfactory (aka will meet the given success criteria). (S)he's been there, (s)he's seen that. And as the one who knows what to expect, the chef is more probably able to detect all those very early warning lights and propose corrective actions.
Let me emphasize it again - micro-managing all the actions is not the way. Even with experience - it's NOT possible to know all the correct paths. Never ever. The number (of correct, good enough options) is endless.
Baking software
I hope you've already figured it out by yourself - this chef soup tasting story can be easily mapped onto engineering management scenarios. Everything that has been said about the chef above can be directly translated into software development leaders' reality — starting with the role of experience and the importance of probing the effects (the current state of - process, tooling, various stages of deliverable completeness).
The default mode of an engineering manager's work should NOT be to dive deep into every possible (implementation) detail - it's just not feasible (but necessary in carefully chosen, critical situations that demand a more direct approach because of some warning lights flashing). A good engineering manager has to be able to:
- quickly orient her(/him)self in a situational context
- identify the qualities that need to be assessed at this point
- find a way to inspect them efficiently and objectively
- confront the perceived learnings with expectations and past experience of similar endeavors
In other words - to "taste the engineering soup".
I think this metaphor is useful not just in calibrating your efforts (as an engineer manager), but also (as it's very "visual") can be very helpful in clarifying the meaning and importance of the engineering manager role: why is it needed, what value does it provide and what kind of input can one expect from a person bearing such a role.
