Private corporate batches, live online cohorts and 1-on-1 mentoring in building a training agenda from a client's real stack — needs analysis, module mapping, lab design, sequencing and assessment — taught by a practitioner who runs it in production.
20 years across DevOps, SRE and Security · 10,000+ engineers trained · Trained teams at JPMorgan Chase, Verizon, Nokia and the World Bank
Principal DevOps Engineer & Architect
Rajesh builds every private agenda the same way: a discovery call that inventories the actual stack and constraints, a baseline read of where the team currently is, then a module list assembled against that inventory rather than lifted from a template — with topics that do not apply removed instead of padded. Twenty years across DevOps, SRE and Security and 10,000+ engineers trained across corporate batches mean the sequencing decisions are grounded in what reliably breaks: labs that cannot run behind a corporate proxy, prerequisites nobody checked, day-one environment setup eating half the schedule, and assessment bolted on at the end instead of designed in from the start.
Twenty years across DevOps, SRE and Security, in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe and others. He has trained engineers at JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus — more than 10,000 people personally. He teaches what he runs, not what he reads.
You are booked with a named engineer, and that is who turns up. Marketplaces and larger providers rotate whoever is free, so the person who sold you the agenda is rarely the person teaching it.
The same trainer is available for the next engagement, which matters when a team builds on what it learned last time.
Your batch is assigned a named trainer before it starts, and that is who teaches it. See the full faculty.
Engagements are matched on the tool, not the calendar. For Agenda that means a trainer who has run it in production — building a training agenda from a client's real stack — needs analysis, module mapping, lab design, sequencing and assessment — rather than whoever is free that week. You are told who is teaching before you commit, and that person is on the discovery call that shapes the agenda.
Where a batch is large enough to need a second trainer, the pairing is declared up front. The lead trainer stays accountable for the syllabus and the assessment either way.
Principal DevOps Engineer & Architect
Twenty years across DevOps, SRE and Security in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe, IBM/Emptoris, Ness, MindTree and Accenture. He has trained more than 10,000 engineers personally, at organisations including JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus. He teaches what he runs, not what he reads.
Teams of 8–30
Custom agenda, your timezone, onsite or online, NDA-friendly.
Request a quoteIndividual engineers
A private instructor and a curriculum built around your goal.
₹99,999Individuals who want peers
Scheduled batch, max 8 to 10 hours of live instruction.
₹34,999A private batch starts with a discovery call. We look at the stack you actually run — the CI system, the cloud, the constraints — and map the agenda onto it, so examples use your topology rather than a generic one.
Delivery is onsite at your premises, live online, or hybrid, scheduled around your release calendar rather than ours. Batches run 8 to 30 engineers.
Every attendee leaves with recordings, slides, lab repositories and a completion certificate. You receive an attendance and assessment report. Invoicing supports PO and GST.
Talk to us about a private Agenda batchAn agenda is the contract between what a team actually needs and what a trainer will actually deliver. A real one is not a list of topic titles. It states, module by module, what the attendee will be able to do afterwards, which tools and versions the demonstrations run against, what the hands-on work is, how long each block takes, and how competence will be evidenced at the end. Anything less is a brochure, and brochures are why so much corporate training produces attendance rather than capability.
Building a useful agenda is a discovery exercise before it is a writing exercise. It starts from the estate: which cloud accounts and regions, which CI system, which orchestrator, which ticketing and source-control tools, which language runtimes, which constraints — change freezes, regulated environments, restricted machine access, split timezones. It also starts from people: the current baseline, the target behaviour, and the specific tasks the organisation wants performed differently in ninety days.
Only then does the module list get built. Topics that do not apply to the estate are dropped rather than padded through; topics the team is already fluent in get compressed; the difficult middle — the part where a tool meets a production environment that does not match its assumptions — gets the time freed up by both. The output is a versioned document that a sponsor can approve, a trainer can deliver against, and a learning-and-development team can audit afterwards.
Training budgets are now scrutinised the way any other spend is. A sponsor approving a five-day engagement wants to know which specific tasks will be performed differently afterwards, and "introduction to" as a module title does not answer that question. The agenda has become the artifact that gets approved or rejected, long before anyone books a date.
At the same time, the failure mode of generic training has become well understood. A course built from a vendor template teaches a reference architecture nobody in the room operates. Attendees follow along, complete the labs against a sample application, and return to an estate where the pipeline, the cloud account structure, the approval gates and the naming conventions are all different. Transfer collapses, and the organisation concludes that training does not work.
The correction is not more content but better targeting — fewer topics, chosen against a real inventory, sequenced so each one is usable before the next starts, with hands-on work performed against the tooling the team goes back to. That is a design discipline in its own right, and it is what separates a private corporate batch from a public course with a company logo on the cover.
The discovery work that everything else depends on. Separating the sponsor's stated problem from the underlying capability gap, establishing a baseline across the group rather than assuming one, and capturing the constraints that will later decide whether a lab is even runnable.
Topics: Sponsor interview: the business outcome behind the request · Baseline assessment across a mixed-ability group · Stack inventory: cloud, CI, orchestration, source control, ticketing, runtimes · Constraint capture: change freezes, network policy, machine access, timezones · Distinguishing a training problem from a process or tooling problem · Scoping: what this engagement will deliberately not cover
Turning a gap into objectives that can be checked. Writing outcomes as observable behaviour rather than exposure, choosing the right level of demand for each one, and testing every objective against the question of how you would know it had been achieved.
Topics: Outcomes as behaviour: what the attendee can do afterwards · Levels of demand — recall, apply, analyse, design · Writing objectives that are checkable, not aspirational · Aligning objectives to job tasks rather than tool features · Avoiding 'understand', 'learn about' and 'be familiar with' · Objective-to-assessment traceability
The core translation step. Taking the inventory from module one and building the module list against it — selecting topics that apply, compressing what the team already does well, and expanding the areas where the tool meets the client's real environment rather than a reference one.
Topics: From inventory to candidate topic set · Selection criteria: applicability, risk, frequency of use · Compressing known ground without insulting the audience · Expanding the difficult middle where tools meet real estates · Substituting examples so demonstrations use the client's topology · Handling mixed audiences and optional deep-dive tracks
Order and duration, which are design decisions rather than administrative ones. Building the dependency graph between modules, deciding what must be usable before the next thing starts, and budgeting time across demonstration, hands-on work, questions and the recovery slots every real delivery needs.
Topics: Dependency mapping between modules · Front-loading environment setup versus deferring it · Time budgeting: demo, hands-on, discussion, recovery · Where to place the hardest material within a day and within a week · Optional and stretch content for uneven pacing · Contingency: what gets cut first when a day overruns
Where agendas most often fail in practice. Designing hands-on work that runs inside the client's actual constraints, specifying prerequisites precisely enough that they get met, and building an environment plan that survives corporate proxies, restricted laptops and missing permissions.
Topics: Lab design: one objective, one observable result · Environment options: attendee-provisioned cloud, local VMs, containers · Prerequisite specification and pre-delivery verification · Corporate constraints: proxies, egress rules, admin rights, licensing · Failure planning: what happens when a lab will not start · Lab repositories, reset scripts and reproducibility
How the agenda proves it worked. Designing assessment that matches the objectives written in module two, choosing a capstone that requires the modules to be combined rather than recited, and producing the attendance and assessment reporting a corporate sponsor expects.
Topics: Assessment types and what each one actually measures · Designing a capstone that integrates rather than repeats · Rubrics and consistent marking across a batch · Formative checks during delivery versus summative at the end · Attendance, assessment and completion reporting · Certificates and what they should and should not claim
The agenda as a living document. Presenting it for sponsor approval, versioning it so changes are traceable, capturing feedback during and after delivery, and revising it for the next batch instead of shipping the same file indefinitely.
Topics: Presenting an agenda for sponsor and procurement approval · Version control and change history for curriculum · In-flight adjustment: reading a room and reallocating time · Post-delivery feedback that is specific enough to act on · Measuring transfer after the engagement ends · Maintaining an agenda as tool versions change
We rebuild the agenda around the tools you actually run.
Request a custom agendaInterview a sponsor and a practitioner from the same team, reconcile the two accounts, and produce a stack inventory plus a baseline for a mixed-ability group.
Build two module lists for the same technology against two genuinely different estates, and defend every topic you included and every one you dropped.
Take an agenda whose modules depend on material that comes later, build the dependency graph, and reorder and rebudget it into something deliverable.
Redesign a hands-on exercise so it runs behind a proxy, on a locked-down laptop, without admin rights and with no outbound access to arbitrary registries.
Design formative checks, a capstone brief and a marking rubric traceable to a written objective set, then mark two sample submissions blind and compare.
Deliver a full engagement agenda — objectives, modules, sequence, time budget, prerequisites, labs, assessment and reporting — and defend it in a sponsor review.
Billed yearly at ₹9,996
Max 8 to 10 hours of live instruction
Full program, private instructor
8–30 engineers · custom agenda · onsite or online · PO and GST invoicing
Refunds. If we cancel or postpone a cohort, you get a full refund within 15 days. There is no money-back guarantee otherwise.
Terms. Course material remains licensed to the attendee. Read the terms.
Your data. We don't share it with third parties. Privacy policy.
Certificate of completion
The trainer (Rajesh) provided very good sessions on SRE profession. Not only hands-on learning on the tools but also SRE mindset.
Very good training session. Well explained from the basics to the complex concepts. Also tried to cover practicals and demos within the 3 hour sessions. The learning content and videos are of a great deal of help.
Basics explanation was exemplary from Rajesh where he dealt with complicated topics to be simple. Great learning stuff personally for me.
Very detailed explanation and has lots of patience in attending the questionnaire. Thanks again for your wonderful sessions.
Good discussion, helped us to understand different tools in SRE.
Got good lab sessions which kept the new DevOps tool learnings to the point and it helped a lot in my career.
| What matters | YouTube + blogs | Generic online course | Freelance marketplace | DevOpsSchool |
|---|---|---|---|---|
| Named practitioner | No | Rarely | Varies per booking | Yes — same trainer each time |
| Production experience | Unknown | Unknown | Unverified | 20 years, named employers |
| Custom agenda | No | No | Sometimes | Built from your stack |
| Onsite delivery | No | No | Sometimes | Yes |
| Lab environment | None | Sandbox that expires | Varies | Your own cloud — skill goes with you |
| Assessment | None | Quiz | Rarely | Assignments + capstone per module |
| Per-attendee certificates | No | Sometimes | Rarely | Yes |
| Corporate invoicing | No | Limited | Varies | PO and GST |
| Post-training support | None | Forum, time-limited | None | Lifetime forum access |
Tell us the team, the stack and the timeline. You'll get a straight answer, not a sales sequence.
Talk to an advisorPrefer to call or email?
More ways to reach us on the contact page.