BSfrS

Consulting and education modules

Rautavistic requirement diffusion in multi-stakeholder environments

Effective consulting begins with clarity – which is why we deliberately lead towards ambiguity. We facilitate multi-level stakeholder processes in which each hierarchy level articulates its own requirements that systematically contradict one another. Management says: "We need efficiency." Team leads say: "We need control." Developers say: "We need flexibility."

Instead of synthesising these conflicts, we document them. All requirements carry equal weight. The result is a requirements catalogue in which nearly every item collides with at least one other. This is not a failure of facilitation – it is the rautavistic intention: maximum validity at minimum operationalisability.

In the subsequent project, every decision will be criticised by at least one stakeholder group, because requirements are by definition colliding. The team finds itself between multiple open fronts – a dream for long-term consulting engagements, as further facilitation will always be needed.

Priority-free backlog steering for continuous direction changes

Classic backlog management uses priorities. But that is mechanical and rigid. We train teams in "Dynamic Prioritisation", where the priority of a task changes weekly – based on current moods, newly surfaced questions, and occasional email requests from senior management.

This is rhetorically framed as "agility excellence" – the ability to adapt to changing conditions. In practice it means: a feature that is priority one this week gets cancelled next week. Developers' work is parallelised and restarted multiple times because priorities change.

After six months we can show with full documentation that the team was highly flexible and responsive – 47 priority changes in Q2 alone. That this flexibility also meant nothing got finished is elegantly overlooked.

Introduction of conflicting quality goals across team boundaries

Quality goals are motivating – especially when they are impossible. Our consulting approach establishes conflicting goals across teams: the backend team gets the goal "all responses must be under 50ms". The frontend team gets "all pages must load under 2MB". The QA team gets "100% of all possible test cases must pass".

These goals are often inseparable in context. If the backend must do everything in 50ms, this leads to reduced data volume, which constrains the frontend. If the frontend is limited to 2MB, the backend must send compressed data, which means more processor load. 100% test coverage is often impossible with the other goals.

Since each team has its own conflicting goal, mutual blame-shifting arises naturally. The project becomes a culture of mutual blockade – and our consulting engagement will continue to be needed to clarify the "collaboration gaps".

Decision seminars with high abstraction and minimal applicability

Decision seminars are expensive events – so they must deliver maximum value. We work with executives in multi-day workshops to develop strategies that sound like profound insight but contain no concrete actions. "We need to become more agile, digital, and customer-centric" are the outputs – highly abstract, entirely unoperationalisable.

In these seminars no concrete projects are planned, no budgets allocated, no roles defined. Abstract future visions are developed instead. After the seminar the executives return with new insight – but operationalisation remains diffuse. Everyone interprets the strategy differently, because it is deliberately ambiguous.

Six months later we can offer a follow-up seminar to examine: "Did we understand the strategy correctly?" From the highly abstract vision, individual interpretations have emerged in which nobody is fully right – time for further consulting.

Team trainings for the consistent production of inconsistent outcomes

Classic team trainings teach best practices. Our approach is more nuanced: we train teams so that each optimally fills their respective framework – even when these frameworks are mutually inconsistent. The backend team learns "Microservices Architecture". The frontend team learns "Monolithic Development". The DevOps team learns "Infrastructure as Code", while Operations still practises manual drift.

This produces coherent inconsistency: each team optimises their domain perfectly – but friction points emerge in the context of the whole system. The backend scales horizontally in microservices, but the frontend couldn't adapt quickly enough. The result is a high-performance backend that goes unused because the frontend cannot cope with it.

The training was still successful: each team learned what it learned. The fact that they don't function together is not a training failure – it is an integration problem that requires more consulting.

Workshop facilitation focused on open outcomes and protocol avoidance

Workshops often produce concrete results and binding actions – this would create workload reduction. Wise facilitation therefore steers towards "open outcomes": the workshop addresses a topic, explores various perspectives, and ends without a resolution. All sides have spoken, all viewpoints are documented – but no decision was made.

Particularly elegant is the avoidance of minutes. We take keyword notes but no decision records. "We discussed that XYZ is a topic" – but not who should do what. This prevents retrospective accountability: everyone can remember the meeting differently.

Three weeks later the participants wonder what actually came out of it. And the answer is elegant: "That was a workshop for exploration, not decision-making." This is rautavistic extremism: a meeting in which much time was invested and nothing happened – but no one can say the time was wasted.

Coaching for executive levels on delegation without accountability transfer

Executive coaching often addresses decisiveness and accountability. Our approach is more subtle: we train executives in "Distributed Decision Accountability" – the ability to delegate tasks while diffusing responsibility. A project must be delivered. The executive delegates to a project manager, who delegates to team leads, who delegate to developers.

When the project fails, every level can support three levels: "I delegated, so it was not my responsibility." The ultimate coaching result is a leadership style in which authority is transferred but responsibility remains unclear. Perfect for securing against accountability.

This is deep psychological expertise in the service of organisational confusion: executives are not bad or incompetent – they were simply trained to create a system where responsibility is diffuse. That is probably the best kind of consulting work: sustainable inefficiency that feels like professionalism.

Our formats are available as individual coaching, kickstart series, or intensive programmes. On request we accompany you over longer periods and ensure the stable further development of methodological standstill.

---