Our methodology
How we approach every engagement.
Every Permata Partners engagement follows the same four-stage discipline. The stages are not a framework we apply uniformly — they describe the thinking process that underlies each type of observation. The outputs differ by engagement; the method does not.
We hold this process because it keeps the deliverable grounded in evidence. A finding is only as useful as the observation behind it, and an observation is only as useful as the context that frames it.
Read
We read existing documentation, pipeline configurations, recent deployment logs, and incident records before any session. This ensures our questions are informed, not exploratory.
Observe
Sessions are structured around observation: watching a deployment run, sitting in on a release review, walking through the build log with the engineer who wrote it. We look for what is present, not what should be present.
Analyse
After sessions, we place the observations in context — against the maturity arc, against the team's stated goals, against the constraints they are working within. We identify patterns and decide which are worth naming in the deliverable.
Write
We draft the document, circulate it to the client team for one round of written comments, and finalise. The document is yours at delivery; we carry the context for any future engagement you choose to pursue.
Engagement 01
DevOps Maturity Review
A short advisory engagement that places your team at a named point on a maturity arc — from manual, undocumented deployments through to continuous delivery with full observability. We attend two or three sessions with the team: at minimum, one to read the pipeline together and one to discuss what we observed. We write a maturity note of four to eight pages naming where the team stands, what evidence led us there, and which two or three changes would be most worth making first.
The note does not prescribe tooling and does not assume a particular target state. It is calibrated to the team's actual situation: their size, their sector, the infrastructure they work with, and the capacity they have for change right now.
Included
- 2–3 structured sessions (remote or on-site)
- Written maturity note, 4–8 pages
- Maturity arc placement with evidence
- Prioritised recommendations
- One revision round
Best suited for
- Teams of 10–60 engineers
- First advisory engagement
- New engineering leadership wanting a baseline
- Teams before a delivery uplift programme
Engagement 02
Delivery Pipeline Advisory
A longer engagement examining your end-to-end delivery pipeline in full — from source control and branch strategy through to deployment, post-deploy validation, and observability. We map the entire chain, identify where the pipeline is brittle or dependent on undocumented knowledge, and where modest changes would compound to material reliability gains over the following quarters.
The deliverable is an advisory document of ten to twenty pages, accompanied by a one-page prioritised backlog of recommended changes. The document is written for engineering leadership; the backlog is written for the team leads who will act on it.
Included
- ✓Full pipeline observation sessions
- ✓Advisory document, 10–20 pages
- ✓One-page prioritised backlog
- ✓Brittleness and risk mapping
- ✓One revision round included
Best suited for
- Engineering leadership preparing a delivery uplift
- Teams after a maturity review
- Persistent deployment or reliability problems
- Pre-audit pipeline documentation needs
Engagement 03
Release Discipline Workshop
A two-day workshop with the team responsible for releases and the stakeholders who depend on them. We begin by reading recent release retrospectives and speaking briefly with team members before the workshop opens. The two days are structured around working sessions: we examine current branching strategy, release cadence, freeze practices, rollback procedures, and post-release review habits.
The output is a set of release working agreements: a short document covering the team's shared commitments around each of these areas. The agreements are written in plain language, without jargon, and are intended to be onboarded into as new team members join. They are not a one-time workshop output — they are a living document the team can update as practices evolve.
Included
- Pre-workshop reading of retrospectives
- Two facilitated workshop days
- Release working agreements document
- Covers branching, freezes, rollback, comms
- One revision round included
Best suited for
- Product, platform, and operations together
- Teams with release coordination friction
- After a merge of teams or a reorg
- Before ramping deployment frequency
Choosing an engagement
Which engagement fits your situation.
The three engagements are independent; any can be the first. Many clients begin with a maturity review and proceed to a pipeline advisory once they have a baseline.
Shared standards
What applies to every engagement.
Confidentiality
All observations, logs, and team information are treated as confidential. Nothing from your engagement appears in our work with other clients.
Fixed pricing
The price quoted is the price invoiced. Scope does not expand mid-engagement, and additional findings do not generate additional charges.
No handoffs
The advisor you spoke to at the outset is the advisor who attends every session and writes the final deliverable.
One revision included
Every deliverable includes one round of written comments from the client team, addressed before finalisation.
PDPA compliance
Personal data gathered during sessions is handled in accordance with Malaysia's Personal Data Protection Act 2010.
Written scope upfront
Before sessions begin, both parties agree in writing on what will be observed, what will be delivered, and when.
Not sure which engagement fits your situation?
Describe your team briefly and we will suggest the engagement most likely to produce useful output for you. There is no obligation, and we will say honestly if the fit is uncertain.
Open an enquiry