Fixed-scope engagement
Hands-On Team Training
Your team inherited systems nobody fully taught them — or we just built something together and you want your people confident running it. We train your team hands-on, on your actual environment: your cloud, your network, your security tooling. Anything we know how to build, we can teach.
Tell us what’s going onAt a glance
- Best for
- A team that needs confidence on the systems it runs
- Format
- Remote or on-site, standalone or part of handover
- Scope
- A defined audience, agenda, and number of sessions
- Main result
- Practical skill plus labs and runbooks the team keeps
The problem hands-on training solves
Common situation: people complete courses and earn certificates, but still cannot debug the systems they operate. Root cause: commodity training teaches abstractions on toy environments; real confidence comes from supervised practice on the systems your team actually runs, with someone senior watching and explaining why.
What you own when we leave
- A training plan built around your environment and your team’s actual gaps — audience, agenda, and outcomes agreed up front.
- Hands-on labs run against your own systems or a sandboxed copy we stand up — never a generic demo tenant.
- Every lab guide, runbook, and exercise as files in your repo, so the material outlives the sessions and onboards the next hire.
- A written debrief: where the team is now strong, and what to practice next.
Not a slideware seminar or a certificate mill. Working sessions on your own systems.
How we approach it
- 01
Discovery
We read your accounts, configs, and constraints directly (scoped read-only access or exported state), map the real current state, and agree on a written scope and success criteria before any code is written.
- 02
Architecture Decision Records
We write down the key decisions — what we’re doing, the options we rejected, and why — as ADRs in your repo, so the reasoning survives long after we’re gone and you can challenge it before we build.
- 03
Implementation
We build the solution as reviewable Terraform/IaC in small, tested pull requests against your CI, so you watch it land incrementally and nothing arrives as a black box.
- 04
Handover
We walk your team through the repo, the threat model, and the runbooks live, confirm you can apply/destroy/extend it yourselves, and then we leave. You own everything — there is no phase 5 where you still need us.
Engagement shape
Fixed scope like everything else: a defined audience, agenda, and number of sessions, agreed in writing first. Delivered remote or on-site — standalone, or as an extended handover phase of any other engagement.
Fixed price, agreed in writing before we start. You can stop at the decision point and keep everything produced.
- 90-day warranty: anything we shipped that does not behave as documented, we fix at no charge.
- Discovery normally uses scoped, read-only roles you create and can revoke; data handling is agreed before access.
- A Senior Engineering Block is available afterward if the next backlog is better handled as flexible hours.
An illustrative example of the format
## Lab 03 — find and close a public bucket [45 min, pairs]
Runs in: sandbox-team-a (vended from your own landing zone)
1. Find it the way an attacker would:
$ aws s3api list-buckets --query 'Buckets[].Name'
$ aws s3api get-bucket-policy-status --bucket <each>
→ "IsPublic": true on one of them. Which, and why?
2. Read the Terraform that created it (infra/storage/):
the module predates the org guardrail — no public-access block.
3. Fix it the way we fix it: a pull request, not a console click.
Add aws_s3_bucket_public_access_block, plan, apply, re-run step 1.
Debrief: why the org guardrail alone didn't catch this, and where
drift like it hides in your estate. → runbooks/public-exposure.mdFAQ
Questions about this engagement
Who actually does the work?
A small senior practice — whoever scopes your engagement writes the Terraform and hands it over. There is no junior bench, no offshore handoff, no solution architect who disappears after the sales call, and no second team we could quietly hand you to. We deliberately take on few engagements at once, which is how the seniority stays real.
How does pricing work?
Defined projects are fixed scope and fixed price, agreed in writing before we start. Most prices depend on the footprint and constraints, so we do not publish a universal price list. One useful anchor: most first Cloud Security Reviews are $8,500–$15,000 CAD. For a changing backlog, a Senior Engineering Block gives you a prepaid pool of hours to use on agreed work. Tell us what is going on and we will propose the appropriate shape and price; then you decide.
What about availability and capacity?
We run a small number of engagements at once so each gets senior attention. That can mean waiting for a start slot; we give you a written start date before you commit. Fixed-scope projects have an agreed scope and timeline. Engineering Blocks have an agreed size, initial backlog, approval path, and usage model. If your real need is round-the-clock operational coverage, that is a managed-service retainer — which is not us — and we will say so rather than overpromise.
Can we keep you around after the engagement?
Yes. A Senior Engineering Block is a prepaid pool of hours for agreed investigations, reviews, changes, debugging, questions, or small pieces of implementation. It can follow a project or stand on its own. It is not a subscription, managed-service retainer, or emergency on-call service. Hands-on training is also available on your real environment rather than generic courseware. Neither is required; project handovers are designed so your team can run the result without us.