Private corporate batches, live online cohorts and 1-on-1 mentoring in DevOps adoption for engineering managers and technical leads — delivery metrics, team topologies, platform strategy and organisational change — 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 teaches DevOps to managers from the delivery system rather than the tool list: where work queues between idea and production, which measures reveal that and which ones hide it, and what team boundaries and ownership models make a given architecture supportable. Sessions work through the decisions managers actually own — build versus buy a platform, whether to fund a reliability programme, how to move a team to product ownership and on-call, how to answer a risk function on change control — grounded in the same pipeline, observability and platform practice taught to the engineering courses, so the technical claims a manager makes hold up when their engineers hear them.
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 DevOps for Managers that means a trainer who has run it in production — DevOps adoption for engineering managers and technical leads — delivery metrics, team topologies, platform strategy and organisational change — 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 DevOps for Managers batchDevOps for Managers is a leadership programme rather than a tool course. It exists because most DevOps transformations do not fail on tooling — they fail on structure, incentives and measurement. A team can hold every certification going and still take six weeks to release, because the handoffs, approval gates, shared environments and on-call arrangements that actually control lead time are set by managers, not by engineers.
The subject matter is therefore organisational as much as technical. It covers how work flows from idea to production and where it queues; how to measure delivery honestly using throughput and stability metrics rather than activity metrics; how team boundaries, ownership models and cognitive load determine what a team can realistically run; when an internal platform team is the right answer and when it becomes a new bottleneck; and how reliability practice — service level objectives, error budgets, blameless incident review — turns operations from firefighting into a managed function.
It also covers the parts of the job that are unavoidably political. Funding a change that has no feature output for a quarter. Explaining to a risk function why continuous deployment is more auditable than a quarterly release, not less. Handling the engineer who does not want to be on call, the architect who wants a two-year rewrite, and the executive who wants a date. A manager who can hold those conversations with evidence moves an organisation; one who cannot ends up running a DevOps team that is really the old operations team with a new name.
Most organisations are past the first wave of DevOps adoption and into the harder part. The pipeline exists, the containers run, and delivery is still slow — because the constraint has moved from technology to organisational design, and nobody in the leadership chain has been trained to see it there.
The measurement problem is acute. Engineering leaders are asked to justify platform investment, headcount and reliability work to people who read financial statements, not dashboards. Without a defensible set of delivery and stability measures, that argument is lost by default, and the organisation optimises for whatever is easy to count — story points, ticket volume, utilisation — all of which reward the behaviour that makes delivery slower.
The cost side has sharpened too. Cloud spend, platform team headcount, tool licences and the operational load of running microservices are now large enough to attract scrutiny, and reducing them without wrecking delivery requires judgement rather than a spending freeze. At the same time reliability expectations have risen and regulators increasingly want evidence of change control that does not depend on manual sign-off. Managers who can connect team design, delivery metrics and operational risk into one argument are the ones who get the budget.
A working definition that survives contact with a board. DevOps as a change to how work flows rather than a toolchain or a job title; the failure patterns that recur — a renamed operations team, a platform nobody uses, an automation project with no owner — and an honest account of what the transition costs in time, money and disruption.
Topics: Flow, feedback and continuous improvement as the actual content of DevOps · Why 'a DevOps team' is usually a symptom · Common adoption failure patterns and their early signals · Where DevOps, SRE and platform engineering differ and overlap · What adoption costs: time, headcount, tooling, disruption · Assessing your organisation's current position honestly · Setting expectations with executives who want a date
The evidence base for every later argument. Deployment frequency, lead time for change, change failure rate and time to restore; flow metrics from the work-tracking system; how to collect them without a new tool purchase; and the measures that reliably make things worse when a manager starts reporting them.
Topics: Deployment frequency, lead time, change failure rate, time to restore · Where each metric comes from in your existing systems · Flow efficiency, work in progress and queue time · Instrumenting the pipeline and the ticket system to get real numbers · Why velocity, utilisation and lines of code corrupt behaviour · Goodhart's law in an engineering organisation · Baselines, targets and reasonable rates of improvement · Reporting to executives without a vanity dashboard
The structural decision that constrains everything else. Team types and interaction modes, cognitive load as a design limit, aligning team boundaries with system boundaries, and what happens to Conway's law when you ignore it. Includes the practical work of splitting, merging and rechartering teams.
Topics: Stream-aligned, platform, enabling and complicated-subsystem teams · Interaction modes: collaboration, X-as-a-service, facilitating · Cognitive load as a hard constraint on team scope · Conway's law and the inverse manoeuvre · Aligning team boundaries with service and domain boundaries · Ownership models: you build it you run it, and its limits · Cross-functional teams, shared specialists and the hybrid reality · Splitting and merging teams without losing a quarter · Distributed and multi-timezone team design
Enough technical depth to make funding and risk decisions credibly, without pretending to be the engineer. What continuous integration, continuous delivery, trunk-based development, infrastructure as code and progressive delivery actually change about risk — and the specific arguments that convince a nervous stakeholder.
Topics: Continuous integration, delivery and deployment — the real distinctions · Branching strategy and its direct effect on lead time · Environments, test data and why staging is usually the bottleneck · Infrastructure as code and what it changes about audit · Feature flags, canary and blue-green as risk instruments · Build once, promote everywhere · Deployment versus release, and why separating them defuses risk · Where automated testing actually pays and where it does not · Reading a pipeline diagram and asking the right three questions
The most expensive decision a technical leader makes this decade. When an internal platform is justified, how to charter it as a product with real users rather than a mandate, golden paths versus enforced standards, and the funding and adoption model that keeps it from becoming the new bottleneck.
Topics: The case for and against an internal developer platform · Platform as a product: users, roadmap, adoption metrics · Golden paths, paved roads and voluntary adoption · Self-service and the removal of ticket-based operations · Build vs buy vs assemble from managed services · Platform team sizing, funding and chargeback models · Measuring platform success without counting tickets closed · Cloud cost ownership and FinOps basics for managers · Tool consolidation and licence rationalisation
Turning operations from an unbudgeted burden into a managed function. Service level objectives and error budgets as a negotiation tool between feature work and reliability work; on-call design that people will sustain; incident command; and blameless review that produces change rather than a document.
Topics: Service level indicators, objectives and error budgets in plain terms · Using an error budget to arbitrate feature work versus reliability work · On-call rotations, compensation, escalation and sustainability · Toil measurement and reduction targets · Incident command roles and communication during an outage · Blameless postmortems and how to make actions actually happen · Operational readiness reviews before a service goes live · Observability as a management concern: what you can and cannot answer · Reporting availability to customers and executives honestly
How to satisfy assurance functions while going faster. Quality practice that lives inside delivery rather than after it, shifting security left without dumping it on developers, and building the evidence trail that lets an auditor accept an automated pipeline in place of a manual approval.
Topics: Quality assurance versus quality control in a continuous delivery model · Defect management, root cause analysis and where quality metrics mislead · Shifting security left: what developers can own and what they cannot · Dependency, container and infrastructure scanning as pipeline controls · Separation of duties when deployment is automated · Change advisory boards and what can replace them · Evidence, traceability and audit-ready pipelines · Documentation that is worth maintaining, and the kind that is not · Architecture decision records as a lightweight governance tool
The execution module. Choosing where to start, sequencing so early results fund later work, handling resistance from engineers and from executives, hiring and skills planning, and knowing when a pilot has failed and should be stopped rather than extended.
Topics: Choosing a first team and a first measurable outcome · Sequencing a 12-month roadmap so early wins fund later phases · Handling resistance: engineers, architects, operations, risk, finance · Skills assessment, training plans and internal enablement · Hiring for platform, SRE and stream-aligned roles · Communities of practice and internal knowledge flow · Performance management when output is a team property · Communicating progress upward with evidence rather than narrative · Recognising a failed initiative early and stopping it
We rebuild the agenda around the tools you actually run.
Request a custom agendaDraw the actual route from committed code to production including every wait, approval and shared environment, then quantify the delay each one adds.
Pull real deployment frequency, lead time, change failure rate and restore time for one team from existing systems, and present them without a new tool purchase.
Score a team's cognitive load against what it owns, then propose a boundary change with interaction modes and a transition plan.
Define a service level objective and error budget for one real service, then run the conversation where a feature is delayed because the budget is spent.
Take one manual approval step, design the automated control and evidence trail that replaces it, and defend it to a simulated risk reviewer.
Deliver a 12-month adoption roadmap with team changes, platform investment, metrics, funding and explicit conditions under which you would stop.
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
I was looking to improve my understanding of AIOps, and this training helped me achieve that goal. Rajesh Kumar explained the subject in a structured and practical manner. The sessions on different AIOps concepts were informative.
I recently did a SRE Session with Rajesh Kumar from DevOps School and the session was great. Right from 1st day till day 15, we had a very interactive session. Rajesh clarified our doubts and the tool demos were excellent without any hiccups. He simplified the concepts while sticking to the content with a fine balance between theory and practice. Am convinced he is one of the best trainers for SRE & DevOps concepts.
The Rundeck developer session was excellent and highly engaging. I appreciated how well the session was structured, with the theoretical concepts explained clearly and in simple terms. What stood out most to me was the demo — it was both informative and enjoyable. I especially liked how Rajesh walked us through not only the happy path but also the sad path, showcasing common issues and sharing practical troubleshooting tips.
Rajesh's experience and knowledge are exceptional and we learnt invaluable practical knowledge which we can apply in our production environment. Incredibly friendly and gave us a fantastic insight both in-depth and at a high level of the Rundeck product.
Great learning experience from a very knowledgeable instructor with well-prepared course notes. The lab exercises on AWS instance work well to learn the hands-on side of the course.
Rajesh is a very good trainer I have experienced in DevSecOps training. The number of contents in different topics he has posted on the DevOpsSchool public website are amazing and user friendly for beginners and experienced professionals.
| 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.