Platform engineering teams face a constant gravitational pull back toward traditional IT operations patterns - the familiar world of tickets, linear workflows, and reactive firefighting. Like Odysseus resisting the sirens, platform teams must recognize and resist these tempting but ultimately limiting habits to build platforms developers actually want to use. The difference between a platform that thrives and one that stagnates often comes down to one thing: whether your team thinks like an ops crew or a product team.
Main insights
- Traditional ops mindsets focus on ticket processing and linear workflows, while a product mindset prioritizes customer feedback and iterative improvement
- Platform adoption rates serve as crucial health metrics - forcing teams onto platforms eliminates your strongest signal of real value
- Pull-based, declarative infrastructure patterns align better with modern cloud environments than push-based deployment pipelines
- Starting small with willing teams and iterating based on real feedback beats big-bang platform rewrites every time
Steve Fenton, Principal DevEx Researcher at Octopus Deploy, and Luke Philips, Principal Engineer at FICO, shared their hard-won experiences building platforms that developers choose rather than merely tolerate.
You can watch the full discussion here if you missed it.
The ops mindset trap: Why tickets feel safe but hold you back
Traditional IT operations teams often measure success through ticket velocity - how quickly items move from "open" to "closed." This creates a comforting sense of progress, especially when leadership demands visible action. But it obscures a more important question: are you actually building something valuable?
As Luke noted, quoting architect Neal Ford: "Engineers chase after complexity much like a moth after a flame, often with the same result." The ticket-driven approach feels productive because you can see work moving through your queue. The problem is that throughput and value are not the same thing.
The fundamental difference between an ops mindset and a product mindset comes down to this: Are you solving the next ticket in your queue, or are you engaging with actual customers to understand their sentiment and needs?
Steve put it plainly: "When you actually listen to the team, I found out that what I assumed were their problems were not their problems." That single insight - that assumptions about user pain are often wrong - is what separates teams that build platforms people use from teams that build platforms people endure.
Watch for these signs that your team is slipping back into ops patterns:
- Measuring success primarily through ticket closure rates
- Building features based on assumptions rather than user feedback
- Maintaining manual touch points in deployment processes
- Falling back to SSH access and manual configuration during incidents
From push to pull: Architectural patterns that scale
Modern cloud environments demand different operational patterns than traditional data centers. The shift from push-based to pull-based infrastructure is more than a technical preference - it reflects a fundamental rethinking of how systems should behave at scale.
In push-based models, teams build linear pipelines that force changes into production. This creates a persistent temptation for manual intervention when things don't go perfectly. As Luke observed: "There's always that temptation of, once it's pushed, the next step is me to log in and fiddle something in production."
Pull-based patterns, exemplified by GitOps, flip this model entirely. Infrastructure continuously reconciles actual state with desired state declared in version control. If someone manually changes a production environment, the system automatically reverts to the declared configuration. This approach delivers:
- Self-healing infrastructure that corrects drift automatically
- Reproducible environments across development, staging, and production
- Reduced operational burden on platform teams
- Faster, more reliable disaster recovery
The discipline required is real: you must resist the impulse to "just quickly fix" production and instead update the single source of truth. That constraint is also the point - it forces good habits at scale.
Building for pull, not push: Making developers want your platform
The most successful platforms are chosen, not mandated. When teams voluntarily adopt your platform, they become invested in its success. When forced, they look for every reason to opt out - and they'll find them.
Luke described how one early-adopter team became a powerful internal example: directors began sharing how they delivered new capability on the platform without needing excessive SRE overhead. That kind of organic, peer-driven evangelism is far more persuasive than any top-down decree.
The practical approach is to frame platform capabilities around problems teams must already solve. Rather than mandating usage, establish organizational policies and position the platform as the easiest path to compliance. Steve gave a concrete example: "Our organization's policy is you have to do artifact attestation at the point of deployment... Now, if I'm the development team, I can either sit there and work out how to do that myself, or there's a platform over here that is saying, 'Hey, we've solved that problem.'"
This creates genuine pull. Teams can choose the platform solution or demonstrate an equivalent approach themselves. Teams that choose the platform will work to make it successful. Teams that are forced onto it will be incentivized to complain or work around it.
The incremental path: Starting small and iterating
Platform engineering does not require a big-bang rewrite. The most durable platforms are built incrementally, starting with willing teams that have real pain, learning their actual workflows, and solving the smallest high-impact problems first.
Steve's experience is instructive: listening to a target team revealed that his assumptions about their blockers were simply wrong. That discovery refocused effort on what actually prevented delivery, rather than on technically interesting but low-impact features.
Practical steps to get started:
- Run a short survey and one-to-one conversations with target teams to surface real friction
- Reconstruct delivery flows for a few representative teams to identify common bottlenecks
- Deliver one small self-service capability and measure both adoption and satisfaction
- Use success stories from early adopters as internal evangelism to pull in additional teams
Keep the platform thin: leverage open source and vendor tools for commodity capabilities, and concentrate custom engineering on what is genuinely unique to your organization. Every hour spent rebuilding something that already exists is an hour not spent on your actual differentiator.
Measuring what matters: Adoption as a health metric
Voluntary adoption is one of the strongest signals that you're delivering real value. Track not just usage counts but sentiment: CSAT scores, Slack channel activity, whether users answer each other's questions, and whether teams contribute back or actively evangelize the platform to peers.
If you mandate platform usage, you remove that signal entirely. Mandates solve compliance but obscure whether the platform actually eases developer work. Let organizational policy create the requirement, and let your platform create the preference.
Build short feedback loops and iterate quickly. Waiting months to learn whether a capability is useful is a pattern borrowed from the ops world - and it's one worth leaving behind.
If you enjoyed this, find here more great insights and events from our Platform Engineering Community.
If you want to dive deeper, explore our instructor-led Platform Engineering Certified Leader course and connect with peers from large-scale enterprises who are driving cultural transformation.
Key takeaways
- Measure value, not velocity: Ticket closure rates tell you how busy your team is, not whether you're solving real problems. Replace ops metrics with customer feedback, adoption rates, and developer satisfaction scores to get an honest picture of platform health.
- Embrace pull-based, declarative infrastructure: GitOps and similar patterns reduce operational burden, enable self-healing environments, and eliminate the temptation to manually intervene in production. The discipline of updating a single source of truth pays compounding dividends over time.
- Make your platform optional to prove its worth: Voluntary adoption turns developer teams into advocates. Use organizational policy to create the requirement, and use platform quality to create the preference. Mandates mask problems; choice surfaces them.
- Start small, stay thin, and iterate fast: Begin with willing teams, listen carefully to their actual pain, and deliver the smallest useful capability you can. Leverage existing tools for commodity needs and reserve custom engineering for what only your organization can build.
