Skip to main content
    Meet us at Open Source in Finance Forum (OSFF) New York, Convene Brookfield Place, November 4 to 5.Book a meeting
    Book a briefing

    The company · Careers

    Build it. Run it. Answer for it.

    iTmethods has run engineering platforms for regulated enterprises since 2005. Now we build Reign, and we build it with Reign: agents and models write the code, and a named engineer owns the outcome. The people here ship continuously, with a human in the loop on every change, and they are on the call when it matters.

    Open roles

    What is open today.

    Posted roles from the board. If nothing is listed, write to the mailbox.

    Growth Engineer (AI-Native)

    AI-native operator. Reports to the CMO. Partners with the CRO and VP Engineering. Reign: Build, Govern and Operate.

    Canada remoteFull-TimeCorporate

    Apply (opens in a new tab)

    The people Paul Goldman, CEO · Rob Stevens, CRO · Virgil Iordan, VP Engineering · Phi Wan, Field CTO · Tarun Matharoo, CFO

    How we work

    Six things that are true every week.

    Behaviors, described as they happen.

    Earn trust with evidence.

    Every change leaves a record: who asked, who approved, what happened. The record comes from the work itself.

    Could someone else check your work tomorrow?

    Own the outcome.

    We measure the work by what the customer can do afterward, not by tickets closed. From ticket to production, one name stays on it.

    Who is on the call when it stops overnight?

    Be accountable by name.

    Agents and models write. A named iTmethods engineer approves. Decisions are written down, and we say so when something is not ready.

    Would you put your name on it?

    Stay close to the customer and the work.

    The person closest to the work makes the decision, in the open and in writing. Engineers work directly with customers.

    Which decision would you want to own?

    Build AI native.

    We build Reign with Reign. Nearly all of our own implementation runs through Reign Factory, and we hire people who want to work that way.

    What would you hand to an agent, and what would you keep?

    Ship continuously, with humans in the loop.

    Small changes, each reviewed by a person who will run it, go out continuously and teach us something every time. Speed comes from the gate.

    What is the smallest change you shipped that taught you something?

    What the work is

    Hard problems, in an unusual place.

    Almost nothing here happens in an environment we control. The customer’s boundary, access reviews and change windows are the design brief. If that sounds like the interesting part, read on.

    Inside a boundary you do not own

    Systems run as single-tenant dedicated instances, under the customer’s access reviews and change windows. You ask, you wait, and you record what you did with the permission. The people granting it are right to ask why.

    Under a change process someone owns

    Every change lands through an approval path with a named owner on both sides. A model in the change earns no exemption, and the record exists afterward either way.

    Carrying the consequence

    When a pipeline stops, the people who built it are on the call. Work that cannot be operated does not leave our hands.

    What we build

    Build. Govern. Operate.

    Each product stands on its own. Together they are the job.

    Build

    Reign Factory

    Tickets in. Pull requests out.

    Implementation and test capacity for well-specified work, opened as a pull request in your review process.

    Reign Factory →

    Govern

    Reign Gateway

    One governed path to the models your teams use.

    Identity, policy and spend limits on every call, and a record in storage you own.

    Reign Gateway →

    Operate

    Reign Ops

    The platforms you deliver on, operated for you.

    Source control, pipelines and tooling, dedicated and single-tenant, run 24×7.

    Reign Ops →

    Three products, each available today. Where each one stands is on product status.

    Fit

    Who thrives here.

    You will thrive if

    • You have run something in production that other people depended on.
    • You treat a regulated environment as a design input.
    • You write clearly without being chased, and you say so when something is not ready.
    • You like agents and models that work inside a gate a person still holds.
    • You like talking to the customer who uses what you built.

    This is probably not for you if

    • You want to move fast by going around the approval path.
    • You want a defined ticket queue and a defined edge to your responsibility.
    • You want to ship autonomous code that nobody has to stand behind.

    Better to know now than in month three.

    Disciplines

    The functions the company is run on.

    Roles are opened against these functions and the three products above.

    • Platform and product engineering. Building Factory and Gateway, and what ships into a customer instance.
    • Operations engineering. Running Reign Ops: single-tenant dedicated instances, upgrades, backups and the response when a platform stops.
    • Security and compliance. Owning the documented process behind every question a customer asks.
    • Field engineering. Named engineers who sit with the teams doing the work, under the customer’s change process.
    • Commercial and delivery. Owning the contract, the scope and the point where a briefing becomes work.

    Before you write, read what Reign is, Reign Factory, Reign Ops and product status. They tell you more about the work than any careers page can.

    How to apply

    How we decide.

    Apply on a posting above. Not every role is advertised, so if nothing is posted in your area, write to careers@itmethods.com.

    • Say which product or discipline you mean, or say plainly that you are writing speculatively. Both are read.
    • Send one artifact that represents your work: a repository, a written design, an incident review you led, or a document you had to defend. One good artifact tells us more than a list of technologies.
    • Tell us about something you operated that broke, and what you changed afterward. That answer is the most useful thing in most applications we receive.
    • The people you would work with read what you send. We use artificial intelligence tools to help screen and assess applications, and a person makes every advancement and hiring decision.
    • We reply when there is a decision to share, and we tell you when there is no role.
    • We hire slowly and describe a role accurately at the point of hiring. If the description you were given does not match this page, tell us.
    • If you need an adjustment at any stage, say so in your first message and it will be arranged.

    Compensation, benefits and equity are discussed with the person they apply to, against the role that was actually opened. The reason to take this work is the work.

    If this is how you already work, write to us.

    We will tell you whether something is open, and if nothing is, we will say so.