First, find out what’s wrong
We agree what needs fixing before I change anything.
Every job follows the same five steps: TRACE. Walk through them with one made-up example, a sync that reports success while records are missing.
1Trace
The sync says success. Is it right?
First I follow the data from source to destination. Configuration and logs are read only.
- Source
- Devices in RMM
- Integration
- Nightly synchronisation
- Destination
- Assets in PSA and documentation
You get
- Scope and assumptions
- Current-state inventory
- Architecture or dependency map
2Reconcile
A successful job, a missing record
The same asset compared at the same point in time. Job status alone does not tell the whole story.
- RMM · device A
- Present
- PSA · device A
- Present
- Documentation · device A
- Missing
You get
- Evidence and exception register
3Assess
Evidence first. Then a decision.
We discuss what is confirmed, what remains uncertain and which improvement is worth making.
- Confirmed
- A record is missing from the destination
- Still to investigate
- Why the sync misses the record
- Proposal
- Check outputs and report mismatches
You get
- Risk and impact assessment
- Prioritised backlog
- Proposal with acceptance criteria
This is your decision. Implementation is a separate project, with its own scope and approval.
4Correct
Only the change we agreed
After separate approval, I build the check. We also test missing data and an unavailable system.
- Change
- Compare source and destination after the sync
- Acceptance
- A missing record is reported
- Rollback
- Restore the previous configuration
You get
- Implementation in your repository
- Change and rollback plans
- Test results
5Embed
Your team can take it from here
The check gets an owner and a runbook. Together we walk through investigating an alert and maintaining the code.
- Code and configuration
- In your repository
- Runbook
- Checks, error handling and recovery
- Ownership
- A named maintainer on your team
You get
- Operational runbook
- Ownership register
- Before-and-after measurements
- Knowledge transfer
How we start
If the cause is unclear, we start with investigation. If the solution is clear, we agree the implementation.
Investigate first
Quick Check
One environment or a narrow configuration question.
You get: Facts, prioritised findings and a short readout.
Assessment / Discovery
The cause, scope or risk is unclear.
You get: An inventory, evidence, findings and a proposed roadmap.
Straight to implementation
Implementation Sprint
The problem and acceptance criteria are clear.
You get: Configuration or code, tests and a runbook.
Improvement Program
Several connected workstreams need attention.
You get: A phased roadmap with agreed deliverables per batch.
Scheduled specialist help
Technical Escalation Block
Your engineers need scheduled specialist help.
You get: Investigation, peer review or a documented decision.
Advisory
You need occasional review or follow-up.
You get: Planned advisory sessions, without ongoing managed support.
How I build
Configure before coding
Use existing platform features before building something custom.
Keep evidence with you
Collection happens in your environment. Data and credentials stay there.
Separate facts from hypotheses
Each finding has an evidence reference and a confidence level.
Least privilege, safe credentials
Only the permissions the job needs. Managed identity or certificates, no plaintext secrets.
Safe to run again
Running again creates no duplicates. Throttling and temporary failures have defined behaviour.
Checked apart from the job
Output is checked independently of the job, with logs your team can search.
Scope and boundaries
- No staff augmentation or ticket queue cover
- No 24/7 or on-call service
- No managed service, SOC or NOC
- No penetration testing or compliance certification
- Investigation delivers evidence and recommendations; a fix is not guaranteed
You work directly with me
Email me what’s going on. We’ll work out a first step together.
Recognise any of these? Tick them and they’re already in your email.