January 2026 started with a new role and a deliberately bigger change of perspective: I joined Komodor as a Solutions Architect for EMEA.
After five years at Jetstack, I wanted the next step to use the same technical foundation without simply repeating the previous role. Komodor sat at an interesting intersection: Kubernetes, operational context, troubleshooting, AI-assisted SRE and the customer conversations that determine whether a tool becomes part of an engineering system or remains another dashboard.
Why troubleshooting is a systems problem
A Kubernetes failure rarely exists in isolation.
The visible symptom might be an unhealthy pod, a failed rollout, scheduling pressure or a readiness probe. Understanding it can require deployment history, events, resource changes, controller behaviour, node conditions, configuration and the relationships between services.
The technical evidence is distributed. So is the organisational knowledge. One team knows the deployment. Another owns the cluster. A third understands the policy or cloud dependency. Under incident pressure, people spend valuable time reconstructing a shared timeline before they can make a safe decision.
That is the problem space that interested me. The goal is not to remove engineers from troubleshooting. It is to reduce the mechanical correlation work so their judgement can be applied earlier.
Why a Solutions Architect role fits
The role brings together several parts of my career that had previously sat in different proportions.
There is hands-on architecture: understanding clusters, delivery models, security boundaries, integrations and operational constraints. There is customer work: discovery, scoping, review meetings, onboarding, health checks and making sure an intended outcome survives contact with the real environment. There is also product feedback: identifying where repeated customer friction points to a missing capability rather than a one-off request.
A useful Solutions Architect has to move between those levels without losing the detail.
The job is not to produce the largest diagram. It is to help a customer make a good decision, define a credible path to value and surface risk early enough that it can still be changed.
What I am carrying from platform engineering
The platform engineering principles still apply.
Start with the user’s job. An engineer does not want “incident correlation”. They want to understand why a deployment failed and what can be changed safely.
Make the paved road valuable. Adoption created through usefulness is much stronger than adoption created through another mandatory process.
Keep evidence visible. Automation should show the events, changes and relationships behind a conclusion. Trust depends on being able to inspect how the system arrived there.
Measure friction removed. Tool activity is easy to count. Time to understanding, repeated incidents avoided and manual correlation eliminated are closer to the outcome.
Design for the exception. Kubernetes estates vary enormously. A strong default needs a deliberate way to handle workloads that do not fit it.
Where AI helps—and where it does not
AI is most useful here when it shortens the path through a large evidence set: correlating a change with a failure, highlighting an unusual event or turning a timeline into a hypothesis an engineer can validate.
It should not create false certainty.
Operational systems need provenance, constraints and a clear distinction between evidence, inference and recommendation. The engineer remains responsible for a production decision; the system should help them reach that decision with better context and less toil.
That balance—automation without loss of understanding—has been a recurring theme throughout my work. It is one reason the move felt coherent rather than a departure from platform engineering.
What success looks like
The early goal is simple to describe and difficult to do well:
- understand each customer’s operating model rather than assume one;
- connect technical capability to the failure modes they actually experience;
- create an onboarding path that reaches useful evidence quickly;
- help teams build trust through transparent, explainable outcomes;
- carry repeated friction back into product and engineering conversations;
- stay close enough to the technology to challenge an answer that does not fit the system.
The title is new. The motivation is familiar.
I still want to help engineering organisations build platforms that developers love—and to make the days when those platforms fail far less painful.