 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
In our previous blog posts, we dug into the importance of platform engineering, emphasizing its transformative impact on the software development industry. We established that it’s not just a buzzword but a fundamental shift in how organizations create software. However, we haven’t yet explored what this change means for those actually doing the work, particularly for teams used to traditional operational roles.
The most significant obstacle to embracing this transformation is a change in mindset. We’ve already discussed the “what” and “why” of platform engineering; now it’s time to tackle the “how.” To do this, we aim to provide clear, actionable guidelines that Ops teams can follow to transition into a platform engineering role. The first question we’ll address: How does one become a platform engineer?
Transitioning from traditional operations roles to platform engineering involves more than just a new title. It requires a change in responsibilities, skills and mindset. Below, we break down the key steps to help you make this transition smoothly.
From Operations to Product: As a platform engineer, you should see developers as your customers and serve their needs as a product team would. The focus shifts from Infrastructure as Code, common in DevOps, to Infrastructure as a Product. This is crucial because you’re not just maintaining systems; you’re creating a product that helps developers work more efficiently.
Identify Bottlenecks: Before adopting a product mindset, the Ops team needs to identify and resolve any bottlenecks. This is essential for freeing up resources and making room for a new approach. For instance, if a specific process is causing delays or downtime, resolving it will pave the way for adopting a platform engineering model.
Customization and Best Practices: It’s important to strike a balance between customization and following industry best practices. For example, a gaming company’s SDLC will differ from an enterprise-focused software firm. Your platform engineering approach should be tailored to these unique needs but also incorporate best practices to avoid unnecessary complications.
Control vs. Flexibility: Striking the right balance between control and flexibility is key. Too much control can stifle innovation, while too much flexibility can lead to governance issues. Aim to provide enough control for proper governance while allowing developers the freedom to innovate.
Measuring Success: To gauge the effectiveness of the transition, track KPIs like deployment speed and developer confidence. Consider developing a Net Promoter Score (NPS) to measure satisfaction with the internal platform. The NPS could focus on the following metrics:
Comprehensive Guides: Just like any other product, your platform should come with detailed documentation and training materials to assist users.
For startups, the process is often quicker and more flexible. They can rapidly adopt new technologies and easily gather developer feedback. Documentation and automation are key, along with closely monitoring performance metrics like developer NPS and sprint velocity.
For larger companies, the shift is usually more gradual, often starting with pilot projects. Standardization is important, but there should be room for customization to meet different teams’ needs. Existing Ops teams can help identify bottlenecks, and retraining may be necessary for the developers. Regular audits and key metrics help gauge the transition’s success.
In short, the approach to becoming a platform engineering organization will differ between startups and large enterprises, but careful planning and monitoring can guide a successful transition for both.
| Category | Startups | Scaled-up Companies |
| Adoption Strategy | Quick to pivot due to lack of legacy systems. | Incremental changes required due to existing legacy systems. |
| Team Involvement | Easier to involve all developers in decision-making due to smaller teams. | Ops team identifies bottlenecks; need for standardized practices across various teams. |
| Flexibility & Iteration | High latitude for experimentation to find optimal solutions. | Pilot projects act as a “hook” for implementing new practices. |
| Resource Management | Automation prioritized to free up human resources for complex tasks. | Upskilling and retraining may be necessary for existing teams. |
| Evaluation Metrics | Use developer NPS and sprint velocity to measure and adapt. | Periodic audits and KPIs, like successful large deployments, used for evaluation. |
In a recent discussion with the head of infrastructure at an enterprise tech platform for loyalty, customer experience and commerce, we explored the transformative impact of their transition to platform engineering. The company operates in a complex, multi-product environment with diverse teams responsible for various functions. Their transition was gradual, moving from one team and environment to another, fine-tuning ROI, playbooks and user experience along the way. This incremental approach helped secure buy-in from each team for the new model.
First, scalability and management have improved significantly. Previously, developers needed close guidance through each stage of release and deployment. Now a well-defined blueprint has removed the guesswork, making it easier to scale and manage projects.
Second, the shift has led to increased efficiency. Tasks that used to take a week, like creating a new cluster, now only take a few hours. This streamlined approach has also reduced human errors.
Third, the new setup offers better visibility and accountability. All changes are versioned, tracked and committed, providing full transparency. This helps the team understand how each project component fits together, a clarity that was lacking before.
Fourth, overhead has been reduced. The team used to manage multiple toolchains, adding complexity and room for error. Now each team manages a single standardized pipeline, reducing both overhead and risk.
Fifth, the transition has strengthened user management and security. The new approach has improved how the organization handles access, security and backups, resulting in a more robust environment.
Last, the development teams now enjoy greater flexibility and is no longer hindered by operational bottlenecks.
The move to platform engineering has ushered them into a new era of operational excellence, offering benefits in scalability, efficiency and overall effectiveness.
Transitioning to platform engineering is more than just a technological shift; it’s a fundamental change in how a company operates and thinks. This involves breaking down existing silos and aligning everyone, from developers to operations, with a unified vision. Regardless of your company’s size or existing systems, the move requires meticulous planning and a focus on agility and efficiency. Think of it as transforming software development into a well-oiled machine that’s aligned with business objectives and quick to adapt to technological trends.
So, why should this matter to you? The benefits are tangible: enhanced scalability, streamlined operations, improved security and greater freedom for development teams. However, this isn’t a process you can improvise. Monitoring performance through metrics is crucial for understanding what’s effective and what needs adjustment. By keeping a close eye on these indicators, you’re better prepared to navigate the ever-changing technological landscape. In essence, those who successfully make this transition are well-positioned for a promising future. Are you ready to take the leap?
This is part of a series on platform engineering. Read the entire series:
