In October 2020, I joined Jetstack as a Kubernetes engineer and consultant. I expected the role to deepen my cloud-native experience. It did, but the five years that followed also changed how I think about platforms, customers, community and what it means to remain hands-on while operating at broader scope.
My last day was 2 January 2026. By then, the company context had changed through multiple acquisitions—Jetstack, Venafi and ultimately CyberArk—but the thread running through the work remained recognisable.
Help engineering teams make difficult infrastructure safer, clearer and more useful.
Consulting exposes the gap between the diagram and the system
A reference architecture can look perfect while missing the organisation that has to operate it.
Customer environments brought constraints that did not fit neatly into a generic design: existing security boundaries, unusual networks, regulated delivery processes, multiple clouds, legacy systems, team structures and different levels of Kubernetes maturity.
The useful work started after acknowledging those constraints. It meant working with engineers, programme teams, security stakeholders and executives without turning every conversation into a different version of the same technology pitch.
A strong solution is not the one with the most components. It is the one a team can understand, adopt and operate when the people who designed it are no longer in the room.
Staying hands-on changed the quality of the advice
As my scope grew, I deliberately kept building.
That included Kubernetes platforms, custom controllers and operators, delivery automation, integrations, workshops and internal tools. Python was often the fastest route to a working controller; Go provided a natural fit for deeper Kubernetes tooling and distributable command-line applications.
The code mattered, but so did the feedback it created. Implementation reveals the sharp edges that disappear from a slide:
- the API that behaves differently at scale;
- the permission hidden behind a seemingly simple workflow;
- the failure path nobody modelled;
- the operational task that becomes somebody’s weekly toil;
- the abstraction that makes a demo cleaner while making debugging harder.
Remaining close to those details made the architectural conversations more honest.
Training is a platform problem too
One of the most satisfying pieces of work was shaping training environments that could be delivered repeatedly without instructors spending the opening session repairing accounts, clusters or workshop state.
The goal was not simply to automate environment creation. It was to improve the experience for the learner and reduce the operational burden on the people running the course.
That is platform engineering in miniature. There is a user with a job to do, a paved path, a set of guardrails, hidden infrastructure and a success measure that should be expressed in the user’s outcome rather than the platform’s activity.
The same lesson applies to production platforms: self-service is only valuable when people can complete the journey reliably.
Open source made the feedback loop larger
Jetstack also gave me space to contribute beyond individual customer engagements.
Projects such as Version Checker, community tooling and the wider collection of automation I built around Kubernetes and FinOps allowed an idea to be tested in more than one environment. Public code attracts use cases, edge conditions and questions that an internal tool may never encounter.
Open source also creates a useful standard of explanation. A maintainer cannot rely on organisational context or a private Slack thread. The interface, documentation and defaults have to carry more of the meaning.
Sharing failure was more useful than presenting perfection
During those years, I spoke at community events including ArgoCon and KubeCon.
The talks that resonated were not tours of an ideal platform. They were stories about automation failure modes, Kubernetes cost, doom loops and the decisions teams make when a system is already under pressure.
That reinforced something I had learned in customer work: credibility is not created by pretending complex systems are simple. It comes from making the complexity navigable and being honest about trade-offs.
Acquisitions change names faster than relationships
Multiple acquisitions inevitably changed reporting lines, brands and the language around the organisation. They also highlighted what survives a structural change.
The strongest part of Jetstack was the people: deep technical curiosity, generosity with knowledge and a willingness to work through a problem rather than hide behind a boundary. Those qualities do not fit neatly into an acquisition announcement, but they are the part of a company that people carry into whatever comes next.
What I carried forward
Five lessons followed me out of the role:
- Platform engineering is a product discipline. The engineer consuming the platform is a user, not an implementation detail.
- Architecture needs operational evidence. Building and debugging keep advice attached to reality.
- Automation must preserve understanding. A fast path that hides every failure mode creates a different kind of toil.
- Teaching improves the system. If a workflow cannot be explained, its interface probably needs more work.
- Community compounds experience. A lesson becomes more valuable when somebody else can challenge, reuse and improve it.
Leaving was not a rejection of the work or the people. It was a recognition that the next chapter should stretch a different part of my experience: bringing platform engineering, customer architecture and operational troubleshooting closer together.
That chapter became joining Komodor as a Solutions Architect.