Services
I work with engineering organizations that want to release faster and with more confidence. Most of it is advisory, where a workshop or a review answers the question and you carry the work forward yourselves. Some of it is embedded, where I run engineering part-time until you’re ready for a permanent leader. The goal is the same either way: less guesswork in production, more trust in the release process.
Independent, and currently taking on new engagements.
Advisory and workshops
Time-boxed work where you are buying the expertise rather than the hours. Most engagements start here.
Feature flagging workshops
Hands-on sessions for engineering teams who are either starting with feature flags or trying to get out from under the ones they already have. We cover the patterns that hold up in production, the failure modes that don’t, observability for flag evaluation, and how to roll out OpenFeature without a rip-and-replace.
Who it’s for: teams who’ve outgrown ad-hoc toggles and want a flagging strategy they can trust on a Friday afternoon.
Typical shape: one or two days on site or remote, fixed price, with a written summary of what the team decided.
Implementation consulting
OpenFeature end to end, from a maintainer’s perspective. Hands-on rollout work: integrating OpenFeature into your stack, wiring it into OpenTelemetry for SRE-grade observability, building the internal tooling around evaluation and audit, and unblocking edge cases by going to the source. As one of the project’s maintainers I can shape the spec where it needs to bend, and help the in-house team carry the work forward after I’m gone.
Who it’s for: teams adopting OpenFeature without in-house insider context, and anyone hitting the edges where the spec meets reality.
Typical shape: a defined project with a fixed price, a recurring day a week while the rollout lands, or embedded with the team as a senior engineer for a defined stretch.
Spec sessions
Implementation is getting cheap, and the agreement about what to implement is what stays expensive. That agreement used to arrive free, as a byproduct of people grinding through the work together. It doesn’t anymore.
A spec session is a facilitated conversation with one output: a written record of what the system should do and why, that everyone in the room has agreed to. I run the room, the team decides, and you keep the spec.
Who it’s for: teams generating code faster than they can agree on what it should do, and leadership teams who suspect the bottleneck has moved from writing software to deciding what to write.
Typical shape: a half-day or full-day session built around a real piece of upcoming work, with the spec as the deliverable. Usually the start of a longer engagement rather than a one-off.
Worth saying plainly: this comes out of Left of the Loop, a working theory I’m building in public rather than a proven framework. The session produces a real spec either way. The wider practice is something we would be testing together.
Developer experience advisory
Ongoing input on the parts of the engineering organization that determine whether your release cycle is a strength or a tax: tooling, testing, CI/CD, build systems, code quality, internal platforms. I’ve spent most of my career in this work, and the goal is to make it boring in the best possible way.
Who it’s for: platform, DevEx, and tooling teams who want a senior outside perspective without committing to another full-time hire.
Typical shape: a recurring half-day or day a month, or a fixed-scope review with recommendations.
Fractional engineering leadership
Engineering leadership without the full-time hire. I take the Head of Engineering or CTO role part-time, setting technical direction, making the architecture and build-versus-buy calls, growing the people, and turning delivery into something the rest of the business can plan around.
What it usually involves:
- Technical direction. Architecture and platform decisions, with the trade-offs written down so the next person can follow the reasoning rather than inherit a verdict.
- Release confidence. Making shipping routine: environments, CI/CD, testing strategy, feature flags, and the incident practice that catches what slips through.
- People and structure. Hiring, onboarding, team shape, career growth, and the day-to-day leadership work that decides whether good engineers stay.
- Translation. Being the person in the leadership meeting who can explain what engineering actually costs, and the person in the engineering room who can explain what the business actually needs.
- The room. Getting the team to a shared, written picture of what they’re building before anyone starts building it, which is where most delivery problems actually begin.
- A handover. The aim is a permanent leader who inherits something that already runs.
Who it’s for: companies with their first one or two engineering teams. Founders who’ve outgrown running engineering themselves, companies in the gap between two engineering leaders, and leadership teams who want senior judgment for a defined stretch rather than forever. Past a couple of teams you want a full-time leader, and I’ll say so.
Typical shape: one to two days a week, three to six months, at a fixed monthly fee. Shorter reviews and one-off leadership sessions work too.
A different shape? Those are the common roles, not the only ones. Describe the gap and I’ll tell you honestly whether I’m the right person to fill it.
Speaking
Conference sessions, keynotes, and in-house talks on feature flagging, observability, developer experience, open standards, and where engineering work is moving in the age of agents. I speak as a CNCF Ambassador, an AAIF Ambassador, and an OpenFeature maintainer and technical steering committee member, which means the material comes from inside the projects, and from having had to make it work in production first. English or German, solo or co-delivered.
Recent stages include KubeCon, Devoxx, ContainerDays, JNation, Cloudland, and JavaCro. Community conferences and meetups are usually travel-only, corporate events and internal sessions are paid engagements.
Who it’s for: conference organizers looking for a session that isn’t a vendor pitch, and engineering organizations who want an outside voice to open an internal event.
Upcoming dates, topics, and formats →
How an engagement starts
- A short call. Half an hour, no charge. You describe what you’re trying to ship and where it’s stuck.
- A written proposal. Scope, shape, duration, and price on one page. If I don’t think I’m the right person, you’ll hear it here.
- The work. A fixed monthly fee for ongoing engagements, a fixed price for workshops and defined projects.
- A handover. Whatever I build or decide gets written down and left with your team.
How to get in touch
Book half an hour, or send a short note with what you’re trying to build, where it’s stuck, and roughly when. I’ll come back honestly about whether I can help.