“I no longer know where the problem is.”
Team, CTO, product, process, architecture: the explanations already exist. Perceptions have to be separated from reality.
Independent advisory · Product & Engineering
You no longer know exactly where the problem is.
Deadlines slip, priorities shift, tensions rise — and everyone has an explanation: the team, the CTO, product, process, architecture. I step into your Product & Engineering organization, understand what is really going on, and establish what needs to change, before getting it back on track with your teams.
The diagnostic answers four questions.
- What is really going on?
- Why?
- What needs to change?
- In what order?
When to call me
The symptoms pile up. The cause stays invisible.
The trigger can be growth, a client that has become dominant, a reorganization, an acquisition — or the moment when what used to work stops working.
“We’ve grown, but the way we work hasn’t.”
What worked yesterday can become a brake as soon as the size, the product, or the constraints change.
“Everyone is working, but nothing becomes predictable.”
Sometimes the problem lies in the interfaces and the decisions, not in the team’s ability to write code.
“We have to change something, but what?”
The right change may be organizational, managerial, product, or technical. You need to know before you act.
Core offer
Product & Engineering Diagnostic
A short, immersive engagement to understand what is holding things back, separate symptoms from causes, and decide what to change, in what order.
€10,500 excl. VAT
- 01System map
- 02Symptoms ↔ causes
- 03Critical decisions
- 04Action plan · 90 days
The diagnostic can end there, or lead to a transformation carried out with your teams.The transformation →
Look wide enough to find the real problem. Go deep enough to verify it.
Who you work with
I’m Charles Granet, an engineer and technology executive. Twenty years across product, software engineering, quality, and team transformation, including five as SVP Technology of an international healthcare group.
I can go from a conversation with a CEO to an architecture or code review, then back up to the level where the decision has to be made.
Open in the analysis, firm in the decision. I listen to everyone without adopting anyone’s story; once the diagnosis is made, I don’t water down the decisions it calls for.
What I don’t do
- Install SAFe or any other method because there supposedly has to be one.
- Supply developers through staff augmentation, or rent out technical leadership by the month.
- Sell regulatory expertise: I know these constraints, but that is not my line of work.
- Extend an engagement with no objective. Success means an organization that works without me.
In practice
Understand before changing.
The typical request
The CEO of a startup watches the product and engineering team get bogged down in internal tensions, without knowing whether the problem lies with the team, the CTO, or the process.
This is exactly the situation the diagnostic exists for: consult, let people talk, observe, look for weak signals — and build a picture of the system before drawing any conclusion.
Healthcare software company · diagnostic requested by the CEO, then transformation
A major client puts the organization under strain.
Problem
A small company signs a pharmaceutical client out of all proportion to its size. Delays and tensions pile up; the team works harder, yet nothing becomes predictable.
Diagnosis
The problem is not effort but delivery predictability. Behind it: poorly divided subcontracting and an aging platform, built too much for engineers and not enough for business users.
Decisions
Golden rules for releases and for working with the client. Autonomous subcontracting on independent modules. Migration to Python 3 initiated, then a new platform designed for project managers.
Impact
Markedly more predictable releases and schedules, a reassured client. The diagnostic led to my joining the company, then to the full transformation.
I didn’t start by rebuilding the platform. I started by understanding the problem, then dealt in order with delivery, organization, subcontracting, technology, and product.
International healthcare group · in a technology leadership role, after several acquisitions
Several inherited platforms, an organization to rebuild.
Problem
Successive acquisitions bring in about six platforms and their teams, across several countries, under a tightening budget.
Diagnosis
Each platform reviewed with its teams. For each one, a decision: keep, shut down, converge, or transform.
Decisions
Restructuring of an engineering organization of about fifty people. Trade-offs on staffing, vendors, and software, headcount reductions included.
Impact
A rationalized portfolio, a restructured organization, an engineering budget reduced several times without halting the evolution of the main product.
The real issue was not the budget: it was deciding what should keep existing, how to organize people around it, and which technology should survive.
First conversation
You don’t need to know exactly what’s wrong.
Tell me what has changed, what worries you, and what you have already tried. Thirty minutes is usually enough to tell whether a diagnostic makes sense.
Talk about your situation