Turn an engineering leader’s intuition into a number they can defend
Batyom reads your code and your organisation together, and answers three questions: what changing your software costs, what causes that cost, and where to start reducing it.
two months
what took two weeks two years ago
A closed number of organisations. It starts with a thirty minute conversation.
The cost nobody puts on the books
A feature that took two weeks two years ago now takes two months and three teams. Nobody made a mistake. The system stopped absorbing change.
There is never one cause. The way the software is built and the way the teams are drawn keep hardening each other, and it costs more every year.
You feel it first on the work that crosses boundaries. An initiative touches four teams, waits on reviews nobody owns, and lands at twice the estimate. Every explanation is plausible and none of them is measurable.
two weeks, one delivery
two months, three teams
The difference never landed on any budget, and nobody can say where it came from.
What changed
Agents now write code inside that structure, and they harden it faster than anyone can see.
The output goes up while the shared understanding of the system goes down. Across the market, a quarter to forty percent of engineering capacity already goes into work that the state of the system makes necessary.
Three answers, in this order
-
What changing your software actually costs
One figure per component and per initiative, not a departmental average.
-
What causes that cost
Coordination, the state of the software, waiting on process, told apart instead of added up.
-
Where to start reducing it
One move, named on the component that deserves it.
Where we sit
An engineering management tool tells you how delivery is going. A financial reporting tool tells you how much was spent.
In between, nobody tells you why that system costs what it costs, and what to change so that it costs less. That is the question a board asks and an engineering leader answers from experience.
- Upstream
Engineering management
Tells you how delivery is going
- In between, empty today
Batyom
Tells you why that system costs what it costs, and what to change
- Downstream
Financial reporting
Tells you how much was spent
How we know
We read the code and the organisation together, because read apart each one shows half the picture.
Every number traces back to the source that produced it. The observed score is one thing and the estimate in euro is another, and we never mix the two.
The error on an estimate is always declared. A number you cannot argue with is a number you cannot defend.
- Version control
- Project management
- Continuous integration and delivery
- Agent gateway logs
The observed score
What the code and the calendar actually say, before any conversion into money.
The estimate in euro
Kept apart from the score, and read in your own context.
The error is declared always, not on request
What you do with it
The move is named on the component, not on the org chart: which shared component needs a single owner, which one should be split, where a dedicated team pays for itself within a quarter.
And people of ours read that recommendation back in your context, because no inference sees everything that matters about an organisation.
-
The product says where
The component, the ownership contest around it, and the spend it keeps generating.
-
Our people say how
Who touches it, in what order, and which conversation is prepared beforehand.
Who is behind this
Batyom comes out of QMates. We have done this work by hand, in dozens of organisations, long before it was a product.
Two thirds of this market still buys the diagnosis from a consultant. That consultant was us.
Powered by QMates
-
Fabrizio Machella
CEO
-
Nicola Moretto
CTPO
What engineering leaders told us
How do you calculate these things? That is the whole product.
Chief technology officer, fintech
The cost benefit analysis is the easy part. Getting the change accepted is the hard part.
Engineering manager, regulated sector
What I do not have today is one view of the data sitting in different systems.
Head of engineering, consumer marketplace
How you buy it
An annual subscription, priced on the number of developers.
You start with a paid trial that is refundable against a baseline agreed before it begins, so that at the end there is something to argue about.
- A paid trial, refundable against a baseline agreed before it begins
- Then an annual subscription, priced on the number of developers
- At the end, something to argue about instead of an impression
The design partner programme
We are choosing a small number of organisations to build Batyom with. Internal development, several teams that have to coordinate.
- A thirty minute conversation about your context
- Early access to the product
- Weight on what gets built next
In exchange: your feedback, and permission to quote you if it helps.
Your application
Four fields. We read the organisation from the domain of your address.