I turn technically messy problems into products teams can build
Twenty-five years where complex engineering systems meet the people who build and use them — Ericsson, Telenor, and now Sweden's Social Insurance Agency.
How I work
Customer first and the people who build for them
Every decision I make traces back to two groups: the people who use the product and the people who build it. I have yet to meet a delivery problem that wasn't, underneath, one of them going unheard. It is why I start with interviews rather than roadmaps, and why team satisfaction sits on my dashboard next to cycle time — not as a nice-to-have, but as a leading indicator.
Measure before I change anything
I baseline the current delivery reality in the first two weeks. It turns improvement arguments from opinion into arithmetic, and it gives the team a win they can see.
Make complexity buildable
Business rules, UX designs and architecture constraints have to arrive at a developer as one coherent, testable thing. That translation is the job I have been doing in one form or another for 25 years.
Protect focus, publish the trade-off
Most delivery problems are intake problems. I make unplanned work a visible decision rather than an invisible tax, and I absorb the stakeholder pressure instead of passing it down as urgency.
Outside the delivery plan
Teaching is where I started and it never really stopped — I've taught object-oriented programming and database design at university level, mentored master's students at BTH and Hyper Island, and now build training content at AgilHus for teams learning lean product development. Languages are part of the same thread: English, Swedish and Persian, and a long-running interest in how people identify themselves to systems — the subject of my MSc thesis on user identification in ubiquitous computing.
Padel tennis: a game that rewards placement and reading your partner far more than power, which is probably why I like it.
And reading books, constantly.