The dualism of effectiveness & efficiency (some would even say: the dichotomy (!))  is one of the most favourite topics of all Lean aficionados, Kanbanistas & other Agile-minded peeps (including prophets of Scrum ...). To be frank I've written about it on several occasions as well, in quite an opinionated way - as a dedicated Lean practitioner I've always preferred the former (& I still do!).

But I've learned (on the way ...) that there are some organisations that (to my honest amazement) quite deliberately bet on efficiency. Why so? And what's the practical difference?

Let's skip the theory & consider a very simple example instead:

There's a multi-team engineering unit that produces and maintains a software product. Teams work on new features, according to whatever planning & delivery routine they've established, when suddenly ... one of the end-users finds a bug. Nothing critical, it doesn't prevent her/him from using the product - nevertheless: User Support Specialists do confirm - it's unquestioningly a bug, not an intended system behaviour.

What would happen in effectiveness-oriented organisation versus efficiency-oriented organisation?

Effectiveness-oriented

Such an org picks its battles wisely. Its prime value is to do whatever brings the highest value. The said ticket gets tagged, documented, classified & prioritised VS the already existing (& already prioritised) tickets. YES, these "administrative" activities are also an effort (surplus one, when you consider that bug could be escalated directly to Engineers), BUT this organisation knows that it's the Engineers who are the bottleneck (they can't do everything - sane prioritisation is essential), not the User Support, who manages the bug backlog (sanitises it & continuously re-priorities).

That's why adding adding work out-of-bottleneck to make the critical-chain work flow more value-oriented is a worthy optimisation (for this organisation).

What are the side-effects of this approach? Small things, that could have been fixed "in half an hour or less", may get stuck in the backlog forever - just because there's always something MORE IMPORTANT (aka MORE VALUABLE). Additionally the more "buffers" (e.g. backlogs) you add into your work system, the more complex it gets - if you can't track your work flow, locate and manage its bottlenecks, you may end up bogged down under tons of bureaucracy & unnecessary process complexity.

Efficiency-oriented

That kind of organisation acts very differently - ticketing systems are EVIL, because they increase the lead time of a ticket (which is exactly the thing to be avoided). User Support Specialist should run directly to the team that owns the sub-system (area/module) that appears to have the flaw, so Engineers can fix the issue straight away. This way teams get more direct & prompt feedback on the quality of their work and (what is probably more important) there's a very clear message that there should be NO COMPROMISE on the quality.

But that comes for the price: in the end Engineers spend time on effort that will bring relatively LESS value than work items they could be working on instead. What is more, it makes Engineers' work harder to plan & estimate - there'll be more unforeseen interruptions & (sometimes expensive) context switching - for no-one knows how long.

Which one is better?

It really depends on your organisation and ... what kind of engineering culture are you aiming for.

The 2nd model (efficiency-oriented) may be completely abysmal when your quality has already deteriorated (because you may end up running in circles trying to fix symptoms of poor quality, burying root causes deeper and deeper ...) while the 1st model (effectiveness-oriented) needs more awareness when deciding about prioritisation (e.g. features VS bugs, technical debt VS business work, etc.), so the delicate balance has to be preserved over time.

IMHO the efficiency-based model can work wonders in the individual-productivity-focused environments: ones that do recognise commitment, glorify "project heroes" (that exemplify unit efficiency), leading by example & above all - the hard work (incl. crunching). No philosophising, no scientific methods, just cutting through whatever's ahead - because we want to crush it ALL ANYWAY!

On the contrary, the effectiveness-based model shines in more pragmatic, data-driven environments: ones that aim to dissect all the challenges ahead & make deliberate decisions about all the (effort) investments on the way. These may be less inspiring (as they don't make such great war-stories ...) & more about cold-blooded, cynical calculation, but that's exactly what resonates more with me (in particular) - because it's about working SMART & making very conscious decisions about what BATTLES TO PICK (next) in the Infinite Game of building great software products.