Ravi had been a DevOps engineer for four years when his director sent him an unusual message. Another product group, in a different building, was planning to consolidate its dozen Kubernetes clusters into one large multi-tenant cluster. The plan was ready, the team was keen, and the change would be painful to unwind once workloads had moved. “You have no stake in their project,” the director wrote. “I want you to give them a second opinion before they start.” Ravi said yes, then spent the evening wondering what that actually meant. This is the story of that review, and why the ability to give and request a sound second opinion has quietly become one of the more valuable skills in a DevOps career.<\/p>\n
Most engineering skills are about building: writing pipelines, automating infrastructure, wiring up monitoring. Reviewing someone else’s high-stakes plan is different. It asks you to read a design you did not write, find what its authors cannot see, and say so clearly without damaging the relationship. Organisations notice the people who do this well, because those people protect the company from expensive, one-way mistakes.<\/p>\n
The same skill works in reverse. Engineers who know when to ask for an independent look at their own big decisions, and how to make that request well, tend to ship fewer regrettable changes. Both directions draw on the kind of structured reasoning explored in a piece on sharpening the reasoning habits engineers use to untangle problems<\/a>.<\/p>\n Ravi’s first meeting with the cluster team was polite and unfocused. They walked him through their whole platform roadmap. After an hour he realised he still did not know what he was meant to assess.<\/p>\n That evening he wrote down a single sentence and sent it to the team lead, Fatima: “The decision I am reviewing is whether to merge your existing clusters into one shared cluster, using namespace isolation, starting next month. Is that right?” She corrected one detail, and from then on both of them knew exactly what was on the table. One decision, clearly bounded. Ravi later called it the most useful thing he did all week.<\/p>\n The team had prepared a tidy slide deck. Ravi asked, politely, for the things underneath it:<\/p>\n Fatima was slightly surprised. “The slides have everything,” she said. Ravi explained that slides are written to persuade, while raw documents are written to work. The gaps he was looking for were far more likely to hide in the detail.<\/p>\n Reading through the material, Ravi noticed several things the slides had smoothed over. Two workloads ran privileged containers for legacy reasons. One team’s batch jobs occasionally consumed most of a node pool’s memory overnight. And the upgrade plan assumed every team could tolerate the same maintenance window, which seemed unlikely.<\/p>\n He resisted the urge to fire off a list of criticisms. Instead he asked open questions in a short follow-up meeting:<\/p>\n The team had solid answers to the first question and partial answers to the second. The third and fourth produced a long silence.<\/p>\n Ravi’s written findings were short. He started with what was strong: the cost case was clear and the namespace design was tidy. Then he listed three concerns, ranked by severity, and was careful to mark which ones he thought should block the migration and which were worth considering. He ended with a paragraph explaining what he had not been able to assess, because he lacked visibility into one team’s compliance requirements.<\/p>\n Learning to write findings this way, honest but not harsh, specific rather than sweeping, is a craft. It is also exactly the kind of evidence of judgement that strengthens a career story, far more than a list of tools. Engineers thinking about what actually moves a DevOps career beyond certificates<\/a> will recognise review work as one of those under-credited signals.<\/p>\n Fatima disagreed with Ravi’s top concern. She felt the privileged workloads could be safely fenced with existing policy controls. Ravi was less sure. For a day it looked as if the review might turn into an argument.<\/p>\n Instead, Fatima suggested a test. They created a staging namespace, applied the proposed policies and tried to reach the privileged workloads from a deliberately misbehaving pod. The policies held for network access but not for one storage path the team had overlooked. Fatima’s design was mostly right; Ravi’s concern was partly justified. The fix took two days, and both of them came away with a better understanding of the problem than either had started with.<\/p>\n That, Ravi realised, is how differing opinions are best resolved in engineering: pin the disagreement to a specific claim, then test the claim.<\/p>\n The consolidation went ahead, a few weeks later than planned, with the storage fix in place, a separate node pool for the batch workloads and a revised upgrade plan that allowed two maintenance windows. The rollback approach was rewritten in detail. Ravi stepped away once his findings were addressed; the review was a one-off, not an ongoing role.<\/p>\n Months later, Fatima asked Ravi to review nothing at all. Instead, she volunteered to give a second opinion on a database decision in his own group. The habit had spread.<\/p>\n If you want to get better at giving and requesting second opinions, a few habits help:<\/p>\n Junior engineers can include review work in their portfolios too. A short write-up of a design you assessed, with the confidential details removed, says a lot about your judgement. Guidance on structuring a beginner DevOps portfolio<\/a> can help you present that kind of work alongside your hands-on projects.<\/p>\n When Ravi described the experience to a friend who works in health care, she laughed and said engineering had simply rediscovered the second opinion. In medicine, people facing a major procedure routinely have another specialist look at the same results, and health websites now offer the request openly. MyMedicPlus, a health-guidance and medical-tourism platform<\/a>, for instance, lists a way to submit an existing diagnosis for an expert’s review among its services. Nothing in this story is meant to weigh in on a medical finding; that is the job of qualified clinicians alone. The comparison simply shows that, in many serious fields, asking a neutral expert to look again is part of doing the job responsibly.<\/p>\n For Ravi, that week changed how he thought about his own work. He still builds pipelines and clusters. But he now sees reviewing, carefully and independently, as part of the same craft, and one that has done more for his reputation than any single project he has shipped.<\/p>\n","protected":false},"excerpt":{"rendered":" Asked to review another team’s cluster consolidation, one engineer learned why giving and requesting an independent second opinion is a real DevOps career skill.<\/p>\n","protected":false},"author":5,"featured_media":1899,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[486],"tags":[],"class_list":["post-1898","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devops"],"_links":{"self":[{"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/posts\/1898","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/comments?post=1898"}],"version-history":[{"count":1,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/posts\/1898\/revisions"}],"predecessor-version":[{"id":1919,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/posts\/1898\/revisions\/1919"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/media\/1899"}],"wp:attachment":[{"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/media?parent=1898"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/categories?post=1898"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/tags?post=1898"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}The first lesson: get the question narrowed down<\/h2>\n
The second lesson: ask for the raw material<\/h2>\n
\n
The third lesson: hunt for the uncomfortable questions<\/h2>\n
\n
The fourth lesson: write it down, gently and plainly<\/h2>\n
The fifth lesson: two views can both be partly right<\/h2>\n
What the team decided<\/h2>\n
Building the skill yourself<\/h2>\n
\n
A habit borrowed from medicine<\/h2>\n