I’m a Senior Software Engineer and Team Lead based in Berlin.
My work has gradually moved from individual implementation toward technical direction: understanding ambiguous or cross-cutting problems, working out the real constraints, and turning them into something a team can execute.
I’ve been writing software professionally since before university, across scientific software, C++ and Windows systems, desktop applications, networking, packaging and automation, data systems, APIs, and event-driven infrastructure. I don’t treat that breadth as a collection of specialties. It mostly means I’m comfortable getting oriented in unfamiliar technical territory and building a useful mental model quickly.
Before AI-assisted tools, that breadth could be tiring to maintain. Now it has become much more enjoyable: I can get oriented faster and spend more time on the actual problem.
How I work
I’m good at working through ambiguity, but I don’t romanticize it.
I prefer clear ownership, explicit decisions, and an ordered way of working. When those things are missing, I’m usually able to work out the uncertainty, identify the real constraints, and turn the problem into something more structured and executable.
A lot of the work is understanding what the system is actually supposed to do: who the users are, which constraints are real, where ownership belongs, what the important trade-offs are, and which decisions can be made now without closing off better options later.
When that context is missing, I tend to go and find it. That may mean talking to users and stakeholders, tracing how a process actually works, separating assumptions from requirements, or making gaps in ownership explicit. I’m comfortable doing that discovery work, even though I much prefer working in an environment where product direction and responsibilities are already clear.
I tend to think in terms of data, interfaces, failure modes, dependencies, and trade-offs. Data modeling is one of the areas I particularly enjoy because a good model often makes the rest of the system simpler.
I write a lot while I work. Design notes, decision records, questions, diagrams, small prototypes — whatever makes the reasoning explicit enough to inspect and change. I prefer lightweight process, but in a team I want decisions and ownership to be visible rather than living only in conversations.
I also like staying close to implementation. Technical direction is more useful when it remains grounded in what the system is actually doing, so depending on the problem I may be writing code, debugging something difficult, reviewing a design, building a prototype, or helping another engineer get enough clarity to own the work themselves.
As my scope has grown, I’ve become more deliberate about that last part. The goal is not to be the person through whom every difficult problem has to pass. It is to create enough direction and structure that other engineers can make good decisions and carry work from design through delivery.