Foundations
Structures that enable decision space
Structures that enable decision space
Proven standards and clear structural guardrails form the core of my operating principles, without ignoring new technologies or trends. I use experiments and prototypes deliberately to gain insights and build sustainable development on a solid foundation.
Decisions give direction; iterative work creates learning. Architecture ensures both can be connected – with manageable complexity and a conscious reduction of invasive changes to existing structures.
- Test new technologies in isolation
- Reliability creates room to act
- Architecture minimizes invasiveness
- Where routine ends, innovation finds its space.
Action
Decisions in context
Decisions in context
Action emerges from the interplay of context, responsibility, and a focus on effective outcomes. Decisions are not viewed in isolation but placed within their domain, systemic, and goal-oriented context – accounting for the given complexity.
The goal is to create orientation and maintain the ability to act, while keeping complexity at an appropriate level.
- Orientation over completeness
- Responsibility over self-protection
- Iteration as a deliberate lever
- Progress comes from action
- Decisions open up further development
- Change grows from continuity
- Development remains shapeable
- Systems enable progress
Development
My personal journey
My personal journey
-
vCard Portfolio Platform
A modularly structured Astro-based content system with a clear separation between structure, content, and presentation. The goal is an exploratory platform rather than a classic CV document – with environment-based visibility, localized content management, and component-driven rendering orchestration.
Platform architecture & content orchestration- JSON-based structure definition as single source of truth for content, order, and composition.
- Component dispatcher for dynamic assignment of content blocks and feature components.
- Separation of structure (structures) and content/i18n (profile.json) for maintainable localization.
- Visibility gating (dev / preview / public) for controlled publishing and progressive release.
Layout system & design architecture- GridLayout system with configurable column sizes, column assignments, and reusable layout patterns.
- Responsive behavior via defined breakpoints (e.g. desktop / narrow / narrow-landscape) instead of ad-hoc CSS.
- Design tokens for consistent visual semantics (colors, spacing, rails, typography) across all components.
- Exploratory UX via accordion/expand mechanics: depth on demand instead of CV-scan optimization.
Product & release strategy- Milestone-driven evolution (e.g. v0.4 → v0.5 → v0.7) with clear goals per iteration.
- Structured Git workflow with traceable changesets (patch/diff-oriented) for reproducible releases.
- Architecture as a stability anchor: changes implemented as non-invasively, consistently, and reversibly as possible.
- Preview-driven validation: test features in isolation before they move into the public branch.
-
Blueprint World Streaming Framework
An architecture-driven Unreal prototype (Blueprint-only) for generating an infinite world along a rail/spline: level segments are streamed on demand (load/unload) in a grid system and loosely coupled via an event-driven approach. The focus was deliberately on DDD, clean architecture, and clear bounded contexts – with a small feature surface but maximum traceability through test automation and arc42 documentation.
Architecture & domain model- Clean architecture as a guiding principle with clear dependency direction and technical isolation of domain logic.
- Domain-driven design with explicit bounded contexts for world, streaming, and traversal.
- Event-driven communication for loose coupling between subsystems and blueprint modules.
- Blueprint-only implementation as a deliberate architectural constraint without hidden code abstractions.
World streaming & grid orchestration- Grid-based segmentation of the world into deterministic cells (chunks) as structural foundation.
- Explicit load/unload policy based on position and lookahead along the rail.
- Clearly defined segment lifecycle with a state model for activation, persistence, and unloading.
- Focus on deterministic states and controlled scaling instead of feature creep.
Rail system & traversal- Spline-based rail as the primary traversal axis with a parameterized progress model.
- Dynamic streaming window along the rail for proactive segment selection.
- Controlled world corridor as an alternative to a broad open-world architecture.
- Orchestration of traversal and streaming across clearly defined domain boundaries.
Quality assurance & documentation- Functional test automation for core flows (stream-in/out, rail progress, segment lifecycle).
- Structured debug and observability mechanisms for runtime validation.
- Architecture documentation following arc42 (context, building block view, runtime view, ADRs).
- Iterative, architecture-driven development with a deliberately limited feature surface.
-
Release Product Owner for a telematics solution in an OEM environment (Daimler Truck).
Responsible for the strategic planning, coordination, and release of company-wide software releases across six teams, as well as concurrent product ownership for a dedicated Scrum development team.
Release governance & orchestration- End-to-end management of release cycles (RC1 / RC2 through go-live).
- Coordination of 6 teams including infrastructure (staging, build pipeline).
- Scope definition and prioritization in alignment with management.
- Schedule ownership including risk and delay management.
- Central documentation and transparency via Confluence.
Product ownership (team PO)- Technical leadership of a Scrum team (5–8 developers).
- Backlog management & release planning.
- Budget controlling and resource management.
- Quality-driven delivery ("quality over throughput").
Transformation & sundown- Managing parallel legacy/cloud operations.
- Actively accompanying the full migration to the Azure-based successor platform.
- Orchestrating the stepwise decommissioning of the monolithic application.
- Aligning technical and organizational dependencies in the migration context.
-
Hex-World Systems Prototype
A systems-oriented Unity prototype for a procedurally growing hex world: biomes as modular tiles, extensible via player placement with snapping/magnetism. The focus was on clean structure (event-driven), traceable debug tools, and a navigation layer (nodes + A* pathfinding) to validate gameplay mechanics as a system early on – including profiling for critical paths.
System design & gameplay mechanics- Procedural start board (hex grid) as a basis for repeatable runs
- Tile spawning & interaction logic (editor/runtime compatible)
- Snapping/magnetism functionality for docking hex tiles including plausibility checks
- Self-expanding world: automatic border generation after placement (reach 1) for variance
Algorithms & navigation- Hex tiles with a node model for defined paths (graph structure) as a foundation for navigation and traversal.
- Path visualization for validating connectivity, traversal, and edge cases in the node graph.
- Idle agent with A* pathfinding on the defined node graph for goal-directed navigation.
Architecture & engineering practices- Event system for decoupled communication (loose coupling) between gameplay subsystems.
- Engine-native procedural rendering of hexagons without external mesh or Blender dependencies.
- Visual debug views for snapping, nearest-neighbor, and placement validation.
- Partial performance analysis to identify critical loops and expansion hotspots.
Transfer to product & PO work- Prototyping as a requirements lab: validate assumptions early and systematically reduce risks.
- Keep complexity manageable through clear models, states, and system boundaries.
- "Observability by design": debug tools as the structural counterpart to telemetry and monitoring in production systems.
- Iterative delivery in small, verifiable increments instead of big-bang implementation.
-
As a Product Owner in the CPQ domain, I worked with my development team to translate complex functional requirements into a working application. I gathered, refined, and translated requirements into sound product decisions that deliver real value to users in their daily work.
Together with the client, existing processes were transformed into quality-assured workflows and the application was continuously evolved into a mature system integrated into the supply chain.
Understanding stable, maintainable, and future-proof software architectures – alongside transitioning between Product Owner and software developer roles – was a constant thread throughout my professional career.
Areas of responsibility- Product ownership in the CPQ domain
- Backlog management and prioritization
- Roadmap and release planning
- Translating domain requirements into product decisions
Processes- Process analysis and workflow optimization
- Agile product development (Scrum)
- Quality assurance and continuous improvement
- Managing complex development workflows
Collaboration & technology- Stakeholder management between domain and development
- Working in multidisciplinary teams
- Technical understanding of software architectures
- Connecting the product and developer perspective
- Focus areas
- Software Engineering
- IT Management
- Social Media Management
Thesis:
Extraction of psychological characteristics with the support of artificial intelligence for the creation of more specific decision profiles
I am a systems thinker focused on clean, sustainable architecture. Individual features are not a side concern for me – they are the smallest common denominator from which stable foundations and scalable systems grow. What matters is how they work together: structures, dependencies, and deliberate decisions over time shape systems that deliver real value and functional quality.
Professionally, as a Product Owner, I am responsible for the evolution of software in complex domain contexts, working closely with interdisciplinary development teams. My focus is on clarity in requirements, sound decisions, and translating domain goals into actionable structures.
Privately, I develop small software prototypes and code snippets as a deliberately bounded space for experimentation. This deepens my understanding of technical relationships and their interactions in requirements engineering – independent of project constraints, but with high standards for clarity, traceability, and structure.
It matters to me that systems remain explainable. Good solutions are robust, traceable, and extensible – even when requirements or conditions change.