Based on a LinkedIn post originally published on 2 March 2026
After several years of building and leading technical teams across different countries, I reached a point in my career when I wanted to make my next direction explicit.
I remained interested in senior technology leadership, particularly across Platform Engineering, DevOps, SRE, Cloud Infrastructure and Security. At the same time, I was deliberately reopening a path toward hands-on systems work, including C++ and lower-level engineering.
At first glance, these directions may appear contradictory. One moves toward broader organisational responsibility; the other moves closer to source code and system behaviour.
I do not see them as opposites.
Technical leadership is strongest when strategic judgement remains connected to an understanding of how systems are actually built, operated and changed.
A career across several layers of technology
My professional experience has never been confined to a single layer of the technology stack.
Over the years, I have worked across software development, infrastructure, enterprise architecture, cloud platforms, security engineering, DevOps transformation and technical leadership.
That journey has included work with organisations such as:
- Compaq and Hewlett-Packard;
- Bank of New Zealand;
- SAP Signavio;
- HelloFresh;
- and other international organisations spanning enterprise and start-up environments.
Each environment required a different balance of technical depth, organisational influence and delivery responsibility.
Large enterprises taught me how technology decisions interact with governance, risk, organisational boundaries and long operational histories. Smaller companies exposed the value of speed, direct ownership and building structures while the organisation itself is still evolving.
The false boundary between management and engineering
Technology careers are often described as two separate tracks:
Individual contributor track
Developer
|
Senior engineer
|
Staff / principal engineer
Management track
Team lead
|
Engineering manager
|
Head / directorThe distinction is useful for defining responsibilities, but it can become misleading when treated as a permanent separation.
Leadership does not erase technical experience. Hands-on engineering does not eliminate strategic judgement. The challenge is keeping both forms of capability credible and current enough for the work being undertaken.
A leader may no longer write production code every day, but still needs to understand architectural trade-offs, operational risks and the conditions under which engineering teams succeed.
Likewise, an experienced engineer returning to implementation work brings more than language syntax. Years of exposure to incidents, organisational constraints, security concerns and production consequences affect how technical decisions are made.
Where my experience creates the strongest value
The roles I considered fell into several related areas:
LEADERSHIP AND TRANSFORMATION - DevOps / Platform Engineering Manager - Security Engineering Manager - Infrastructure or SRE leadership - Architecture and technical transformation ENGINEERING - DevSecOps Engineer - Systems-oriented C++ development - Infrastructure and platform engineering - Security-focused engineering
The leadership roles align most directly with my recent experience. They draw on team building, architectural judgement, cross-functional delivery, operational responsibility and the ability to bring structure to complex technical environments.
The engineering roles represent a more deliberate return to implementation. They are most suitable when an organisation values extensive systems experience and allows time for practical fluency to be refreshed, rather than assessing seniority solely through immediate performance in a narrow coding exercise.
Experience does not remove the need to refresh hands-on skills. Returning to daily implementation requires practice, humility and time—but it also brings decades of context that cannot be recreated through syntax knowledge alone.
Architecture level and close to the metal
Much of my career has involved moving between very different levels of abstraction.
At one moment, the discussion may concern organisational ownership, platform strategy or a multi-year transformation. At another, the problem may depend on operating-system behaviour, network topology, storage architecture, process boundaries or the details of a C++ implementation.
Those levels affect one another:
Business objective
|
v
Organisational ownership
|
v
Architecture and platform design
|
v
Operational model
|
v
Infrastructure and software behaviour
|
v
User and business outcomeA strategy that ignores implementation constraints will eventually collide with reality. An implementation that ignores organisational purpose may be technically sound but deliver little useful value.
My strongest contribution is often connecting these layers: understanding the strategic objective while remaining able to reason about the underlying system.
What experience changes
Seniority is not simply the number of technologies someone has encountered. It changes how risk, ownership and consequences are understood.
Experience brings an awareness that:
- the most elegant architecture may still fail if nobody owns it;
- operational simplicity is often more valuable than technical novelty;
- security must be designed into normal workflows rather than added as an external obstacle;
- platform teams need clear customers and measurable outcomes;
- incidents frequently reveal organisational weaknesses as well as technical ones;
- and sustainable delivery depends on people, communication and trust as much as tooling.
These lessons influence both leadership decisions and implementation choices.
Direct and accountable ownership
Regardless of role title, I value environments where responsibility is clear and decisions lead to action.
Direct ownership does not mean solving every problem personally. In a leadership role, it means ensuring that important work has an owner, teams have the necessary context and risks are not allowed to disappear between organisational boundaries.
In an engineering role, it means understanding the production consequences of a change, validating assumptions and remaining responsible for the behaviour of what has been built.
Accountability is not control over every detail. It is the refusal to let important outcomes become somebody else’s undefined problem.
Location and working environment
My legal employment base is Berlin, and I am a German and European Union citizen. I am open to suitable opportunities across Germany and the wider EU, including relocation where the position justifies it.
I also maintain a base in Moldova and remain open to local employment or genuinely compatible remote arrangements.
I work professionally in English and also speak Portuguese. I do not speak German, so roles requiring professional German from the outset are not a realistic match unless the organisation can operate with English in practice.
The important consideration is not simply whether a vacancy is labelled remote, hybrid or office-based. The working arrangement must be operationally and legally compatible with where the work will actually be performed.
The kind of challenge I am looking for
I am most interested in environments where technology is consequential: where platforms support real business operations, security decisions matter and teams must balance delivery speed with reliability and long-term maintainability.
The ideal opportunity would benefit from a combination of:
- enterprise-scale systems experience;
- cloud and on-premises infrastructure knowledge;
- platform, DevOps and security transformation;
- leadership during uncertainty and operational pressure;
- strong architectural reasoning;
- and direct, accountable ownership.
The exact title matters less than whether the organisation needs this combination and understands how it can be used.
Leadership and hands-on engineering are not competing identities. They are different expressions of the same responsibility: understanding complex systems and helping people change them safely, deliberately and effectively.
This article is based on my original ideas, experience, analysis and conclusions. Artificial intelligence tools were subsequently used as editorial and research assistants to review grammar and wording, improve structure and presentation, organise some arguments into clearer logical sections, and help review references to legal, regulatory and technical concepts.
Where relevant, factual and regulatory references were checked against the sources cited in the article. AI assistance does not replace professional legal, regulatory, financial or technical advice, and the final selection, interpretation, opinions and conclusions presented here remain my own.
Comments
Post a Comment