Think Globally, Change Locally
In 2023, I wanted to test a different way of working.
For several years, I had been thinking about creating my own company. Freelancing was not necessarily the final destination, but I saw it as an intermediate step toward greater independence.
Instead of receiving a fixed salary, I wanted to charge for my expertise on a daily basis, accepting the other side of that equation: a consulting contract can also end much more quickly.
I was looking for more flexibility too. As an employee, changing direction often meant long notice periods. As a consultant, I wanted the ability to reassess an engagement more quickly.
And I wanted to discover something completely different from the environments I had worked in before.
That opportunity came with Kappa Engineering.
I joined as a Full-Stack Consultant, contributing to an application used to manage oil and gas fields and wells.
It was my first serious exposure to this kind of industrial domain.
Learning before changing
The first challenge was not technical.
It was understanding what the software was actually about.
Oil and gas was a completely new domain for me. Before making useful changes to the application, I had to develop enough understanding of wells, fields, workflows, terminology, and the relationships between the different parts of the system.
This reinforced an idea that became increasingly important in my career:
You cannot make consistently good technical decisions if you do not understand the domain around the code.
But Kappa also challenged one of my engineering habits.
Before joining, I was accustomed to workflows where a pull request could remain open for several days before being reviewed and merged.
At Kappa, the team worked differently.
They followed a trunk-based development approach.
Changes were deliberately small and could be integrated directly into the main branch. Reviews could then happen asynchronously.
Initially, I found that uncomfortable.
I was new to the application.
I was new to the business domain.
And the main branch was closely connected to the pre-production version of the product.
My immediate thought was:
What if I push something that creates a regression in a system I still don't fully understand?
Why small changes changed my mind
What made the approach work was not simply the absence of a long pull-request process.
It was everything surrounding it.
The application had a strong level of automated test coverage.
Changes were intentionally kept small.
Instead of accumulating several days of work into one large change, we integrated small pieces continuously.
That reduced the uncertainty around each modification.
A small commit was easier to understand.
Its consequences were easier to reason about.
Tests provided rapid feedback.
And when something went wrong, the scope of the problem was much easier to identify.
What initially looked risky gradually started to feel safer than the workflow I had been accustomed to.
I became an advocate of trunk-based development.
It changed the way I thought about controlling engineering risk:
Sometimes the safest way to change a complex system is not to add more gates around large changes, but to make each change smaller.
Seeing beyond the code in front of you
There was another part of the Kappa experience that influenced me even more.
I worked alongside engineers who had spent years understanding the application and the industrial domain around it.
What impressed me was not simply their ability to code.
It was the mental model they had built.
They could remember details from very different parts of the system and, at the same time, understand how those details fitted into the global architecture.
During a discussion about one small feature, they could immediately see dependencies or consequences in parts of the application that were far away from the code being changed.
That ability stayed with me.
It changed what expertise meant to me.
Expertise was not just:
Knowing more details.
It was:
Knowing how the details connect.
A strong engineer needs to be capable of moving continuously between two perspectives:
the local change in front of them
and
the system around that change.
That led to a principle I still carry:
Think globally. Change locally.
What consulting taught me about responsibility
Kappa gave me many of the things I had been looking for.
I experienced the daily-rate consulting model.
I gained more flexibility.
I discovered a new industry.
And I worked in an engineering environment that changed some of my development practices.
But the experience also revealed something I was still looking for.
My role was mainly focused on implementation.
The team already contained engineers with deep technical and domain expertise, and the nature of my consulting engagement meant there was limited space for me to expand into leadership or people-management responsibilities.
Commercial considerations also became part of the experience.
Unlike salaried employment, consulting made the economic relationship around my work much more explicit. Negotiating the value of the engagement became part of managing my own career.
That was useful in itself.
But by the time I was ready to move on, I knew I wanted the next stage to give me something beyond flexibility and technical work.
I wanted broader responsibility.
Can I implement this well?
Can I influence how the system is designed, how technical decisions are made, and how the people around the system work together?
Kappa strengthened the engineer in me.
It also helped clarify the kind of role I wanted to grow into next.