Your Best Engineers Should Be Building the Future

Imagine it is 2:13 a.m. Checkout is failing. Your most experienced engineer is piecing together logs while another traces the last deployment. By morning, the service may be back. The energy spent recovering it will not be. This illustrative scene carries a leadership cost that rarely appears on an incident dashboard: the product decision delayed, the experiment postponed, the customer improvement pushed into next week.

For a leader, the strategic choice is where expertise accumulates. Keep it inside an endless rotation of manual tasks, and growth brings more work for the same people. Encode it into reusable skills, evidence, and operating policies, and each successful workflow can become a foundation for the next. Teams that start this learning cycle earlier have more opportunities to refine it. Waiting also has a cost: another quarter of operational knowledge that never becomes an organizational capability.

01 / Complexity is spending your engineering capacity

Microservices gave your teams the freedom to ship independently. They also spread the truth about production across services, owners, dashboards, and deployment histories. When a request fails, people must reconnect what the architecture separated. Each new service can add another handoff. A company can invest heavily in engineering and still watch its most valuable attention disappear into the spaces between tools.

One organization. Many products. A shared operating context.

A checkout outage is only one window into the business. A customer app, a partner API, and an internal operations portal may share identity, databases, queues, and cloud accounts. Product teams own different roadmaps, while platform, security, finance, and support must understand the same estate. The leadership opportunity is to connect these perspectives without erasing ownership.

From a web of dependencies to a map of business meaning

A service map tells you what connects. An ontology adds what each entity means and how it relates to the business: a service supports a product, belongs to a team, runs on a resource, changes through a deployment, and is governed by a policy. This is an illustrative way to map your organization into the shared operational context described on the homepage, not a published CloudThinker schema.

Follow one shared dependency: if Identity slows down, checkout, the partner API, and the internal portal may all suffer. Application engineers need the change history. SRE needs the dependency chain. Support needs the affected journeys. Security needs to assess whether access is involved. Leadership needs the scope of business impact. Shared context lets each team ask its own question about the same incident.

Google’s SRE guidance caps operational work at 50% of an SRE’s time, preserving at least half for engineering. That is an operating principle, not an AI automation benchmark. The aim is enduring improvement instead of an ever-growing queue of repetitive work.

02 / Make expertise available whenever the business needs it

In our checkout scenario, the useful question is whether a recent change explains the failing requests. An AI SRE can collect permitted telemetry, correlate the timeline, and test candidate causes against logs, metrics, traces, and deployment changes. A database alarm might be a downstream symptom. The report should show what supports the proposed cause, what contradicts it, and what remains unknown.

An alert should start an investigation. Connected evidence should shape the hypothesis. Your engineers should arrive with a head start. Zero-shot investigation can begin without a human-supplied diagnosis or task-specific example; its conclusions still depend on context and verification.

03 / Turn human judgment into an operating model

1. 01Correlate signals
2. 02Investigate evidence
3. 03Check policy
4. 04Act within scope
5. 05Verify or escalate

The policy gate is where DevSecOps expertise becomes executable. Define allowed resources, tool permissions, approved runbooks, change windows, and escalation owners. Known, permitted actions can run within that scope; actions requiring approval wait for a person. After a change, check service health and user-facing symptoms. If recovery fails, follow the approved rollback or escalate with the evidence.

04 / The ambition already has customer evidence

Amela: root cause and a validated solution in under 30 minutes; incident MTTR moved from hours to minutes. The published story gives no exact baseline or incident sample size.

F88: 80% of daily operations automated and 30% lower AWS spend. The journey began with a read-only pilot, then expanded after the team verified the findings. That sequence matters: trust grew from observable results.

Take Amela’s approach when diagnosis is the bottleneck: improve the system’s foundations and connect the evidence needed to investigate. Take F88’s approach when trust and governance are the bottleneck: begin read-only, validate findings with the team, then expand the permitted work. You can combine both approaches in the same rollout.

05 / Think organization-wide. Earn progress one workflow at a time.

1. 01Choose one service and establish the baseline

   The service owner and on-call lead select a recurring, well-understood problem. Use recent comparable incidents to record time to diagnosis, time to recovery, and human effort. Agree on a pilot target and a stop condition before connecting production.

2. 02Connect context in read-only mode

   DevSecOps scopes access to the selected environment. Connect supported cloud and observability tools, recent changes, and relevant runbooks. Confirm that signals reach the right service and that an investigation can cite the underlying evidence. Keep changes disabled while the team checks the findings.

3. 03Encode the team’s operating policy

   The service owner, security reviewer, and DevSecOps lead define which actions are allowed, require approval, or are denied. For each permitted fix, document resource scope, preconditions, the recovery check, rollback, and the person to escalate to. Test the procedure in a suitable non-production environment before allowing production execution.

4. 04Run the pilot with human approval

   Let CloudThinker investigate and propose actions for the selected incident class. The on-call engineer reviews the evidence and approves changes within the agreed process. Record incorrect diagnoses, failed recovery checks, escalations, and successful resolutions alongside the time saved. A plausible report alone is not a completed incident.

5. 05Expand the work that earns trust

   Review the pilot against the baseline. Allow unattended execution only for repeatable actions that meet your policy and recovery criteria. Add the next service or operational workflow with its own owner and permissions. Keep exceptions routed to people, and revisit policies after failures or architecture changes.

06 / Build an operating foundation for the whole business

Incident response is the opening move. The larger opportunity spans the work that keeps every product running: RCA to explain failures, recovery to restore service, CostOps to challenge waste, Cyber to prioritize exposure, and automation to execute approved procedures. Connect these disciplines through shared context and clear policy, with permissions and success criteria for each domain. That is the direction for CloudThinker adoption: an operating foundation that can grow with the business.

Different teams, shared context, explicit accountability

Six ways to put the shared context to work

The homepage groups these workflows into prevention, response, and continuous improvement. Choose the entry point that matches your team’s bottleneck, then connect the next workflow to the same operating foundation.

07 / Reinvest the hours. Change what your company can build.

Imagine the same team a year from now. More of its routine operations run under policies it has tested and refined. Engineers spend less time reconstructing yesterday’s failure and more time designing tomorrow’s product. Human expertise remains essential: setting SLOs, making architecture decisions, handling difficult exceptions, and deciding where autonomy belongs. The ambition is continuous AI execution, guided by people who understand the business.

Give that returned capacity a destination. Let developers remove a recurring customer frustration. Let operations prepare for the next market launch. Let security strengthen the controls that help earn enterprise trust. Let SRE and DevSecOps turn their best judgment into reusable skills and policies. Then measure the business work that actually ships. Hours recovered become valuable when leadership gives them a purpose.

Choose the first service. Name the owner. Agree on the evidence that will justify the next step. Every workflow you validate is operational knowledge your organization can reuse. Start building that capability now, so the next chapter of growth has more of your team’s attention available to it.

Sources and further reading

• Read Google: Eliminating Toil
• Amela: AWS incident response
• F88: governed hybrid-cloud operations
• CloudThinker incident setup and approval controls