Skip to main content

Posts

Why Dashboards Don’t Fix Customer Experience

The problem with seeing everything and changing nothing Modern companies are exceptionally good at producing dashboards. Sales has dashboards. Marketing has dashboards. Customer support has dashboards. Operations has dashboards. Finance has dashboards. Executives have dashboards combining all the other dashboards. Customer Experience teams are no different. They monitor: NPS; CSAT; CES; response rates; complaint volumes; sentiment; review ratings; support resolution time; churn; retention; journey metrics. The organisation can see more than ever. And yet many customer problems remain unresolved for months. This creates an uncomfortable question: If the company can already see the problem, why is the problem still there? The answer is that visibility is not action. A dashboard can reveal deterioration. It cannot decide what matters. It cannot determine who should act. It cannot resolve conflicting priorities. It cannot execute an intervention. And it cannot reliably determine whether th...

FamilyTree - Dr. med. Jürgen Christian Georg Berendsen

When researching my family history, I occasionally encounter an ancestor whose life deserves considerably more attention than a simple collection of names, dates and places. One such person is my great-great-grandfather, Dr. med. Jürgen Christian Georg Berendsen , born on 19 February 1855 in Schleswig and deceased on 19 April 1932 in Berlin. He lived for seventy-seven years, through a remarkable period of German history. Born in the Duchy of Schleswig before the German Empire existed, he witnessed the unification of Germany, the rapid development of modern medicine, the First World War, the collapse of the monarchy and the establishment of the Weimar Republic. His professional career unfolded during an era in which surgery, antisepsis and medical education were undergoing fundamental changes. But what interests me most is not simply the historical period in which he lived. It is the increasingly detailed picture of the man himself: a child described as physically fragile, a univ...

TOMS - Designing Import and Export Properly: From CSV and Excel to XML, PDF, Calendars, CAD and Open Standards

Import and export initially looked like something I could leave until quite late in the development of my event-planning application. After all, the application already has its own Document model. Guests, Groups, Tables, Seats, contact information, floor plans, images, relationships and event configuration all live inside that model. Saving and loading the application's own Document is obviously necessary, but exporting to other formats could be added later. The more I think about it, however, the more I believe that would be a mistake. Import and export are not just convenience functions added around the edges of an application. They define how the application participates in the world outside itself. A professional desktop application should not become a data island. Users should be able to bring useful information in, work with it, and take useful information back out again. For an event-planning product this becomes especially important becau...

Discovering Distributed Development Before We Had the Modern Tools

Based on a LinkedIn post originally published on 3 April 2026 In the early 1990s, while living in southern Brazil, I worked for a software-development company that produced hospital-administration systems in partnership with IBM. Through that relationship, we had access to IBM RS/6000 systems running current versions of AIX. Our product was deployed across Brazil. That national reach introduced scale, operational pressure and responsibility very quickly. One of the largest engineering challenges was not writing an individual piece of code. It was coordinating the work of several developers and integrating their changes into one reliable product. When several people can write code successfully, the difficult problem becomes ensuring that their individually correct changes can coexist safely. The coordination problem Developers needed to work in parallel. They required enough independence to make progress without waiting continuously for one another, but the company still needed a consis...