How we work.
An engagement with Hydrogen Technologies has four stages. They are not a methodology; they are the rhythm we have arrived at after the kind of mistakes that are only possible to make once.
The shape of an engagement.
The four stages below describe how a typical Hydrogen Technologies mandate unfolds. Their relative durations matter more than their absolute ones — discovery is short, build is long, handover is deliberate. The proportions are not negotiable; the timelines are.
We share this in detail because the most common reason engagements fail is mismatched expectations about how the work will be done. If anything below feels wrong for your organisation, the right response is not to discount it — it is to look elsewhere.
We are direct about this because the alternative is to begin work that should not have begun.
Discovery → Architecture → Build → Handover.
S-01 · ≈ 8 weeks
Discovery
We map the system as it actually is.
Almost every engagement begins the same way: by refusing to begin. For the first eight weeks of any consequential engagement, we do not write code. We observe.
We sit with the operators. We read the postmortems. We trace flows that no one in the room can describe end-to-end. The output of this phase is not a slide deck — it is a single, named, ratified picture of the system as it is, with the fictions removed.
What you receive
- Annotated current-state map of the systems involved
- Decision register tracing key historical choices and their context
- Catalogue of named seams — places where ownership and contracts have quietly diverged
What we ask of you
- Observation access — calendars, channels, repositories
- Two named contacts who can answer questions of fact
- A single hour of leadership attention each week
S-02 · ≈ 4 – 6 weeks
Architecture
We compose the target system before we touch it.
From the discovery picture, we design the system that ought to exist — the contracts, ownership, sequencing, and seams. This is the most carefully written document of the engagement, and the one that will be referenced for years.
Architecture is treated as composition, not invention. We are looking for the shape that lets the organisation move clearly, not the shape that is most clever.
What you receive
- Target architecture document with rationale
- Domain contracts and ownership map
- Migration plan — staged so each step is independently valuable
- Risk register with named mitigations
What we ask of you
- Leadership ratification of the architecture before build begins
- A standing fortnightly architecture review for the build phase
S-03 · ≈ 3 – 18 months
Build
The work itself.
Build is the longest phase of the engagement and, paradoxically, the least interesting to describe in advance. The shape of the work is determined by the architecture; what changes in build is the texture — the cadence, the surprises, the quiet adjustments.
We work alongside our clients' engineers, not adjacent to them. Every line we write is paired with at least one of their engineers, and every architectural decision is recorded as it is made. The system that emerges is not ours; it is theirs from the first commit.
What you receive
- Production-grade systems with telemetry and SLOs designed in, not bolted on
- Architectural decision records (ADRs) for every consequential choice
- Paired engineering throughout — no silent handover at the end
- Continuous risk and runway visibility
What we ask of you
- A single decision-maker on the client side with the authority to redirect
- A fortnightly review with the named architecture group
- Honesty about constraints we have not yet been told about
S-04 · ≈ 2 – 4 weeks
Handover
We engineer the conditions for our absence.
An engagement is not finished when the system goes live; it is finished when the client team can operate, evolve, and explain it without us. Handover is where we earn the right to leave.
We do not believe in long tails of paid retention masquerading as support. If we have done the work well, our absence should feel ordinary.
What you receive
- Runbooks and operational documentation tested by the receiving team
- Training sessions tailored to engineers, operators, and leadership respectively
- On-call and incident response handoff
- A 30/60/90-day review window built into the contract
What we ask of you
- Named successors for each major area of the system
- Time on the receiving team's calendar to learn deeply, not just to receive
Three shapes the work takes.
Most of our engagements are embedded studios. The other two formats exist for situations where that shape is not the right answer.
Embedded studio
Our default and most consequential format. A multidisciplinary team works alongside yours through all four stages, on a single mandate of strategic importance.
Capability sprint
A focused engagement on a well-defined capability — an evaluation suite, a platform foundation, an architectural rewrite. Fixed scope, named outcomes.
Advisory
A standing relationship with leadership. Architecture reviews, design critique, and the kind of judgement that is most useful when it is available before the decision is made.
What we won't do.
A short list, written down so it is referenceable rather than rediscovered each time.
Purely tactical mandates.
Work whose horizon is shorter than its consequences. We will recommend other studios where the right answer is to ship quickly and revisit later.
Time-and-materials structures without named outcomes.
We work to outcomes, not hours. Engagements that cannot be expressed as a named change to the system are not a fit for our practice.
Displacement-only AI work.
We do not take engagements whose only stated goal is reducing headcount. Our AI work makes existing roles more capable, not absent.
Engagements without a single decision-maker.
Where the buyer of the work and the receiver of the work cannot align on the shape of the answer, we will not begin.
If the rhythm above resembles the one you are looking for, we should speak.
Begin a conversation →