As organizations continue to vie for technological advancements, they are finding out that their best keys to success are not necessarily within their consumer-facing offerings. Rather, they are being found within the infrastructure that allows their engineering organizations to work faster than rival organizations. Victor Uzochukwu, a seasoned software engineer with five years experience across several high-growth technology ecosystems, is one such exponent who has seen this shift happen and is advocating a new philosophy that is revolutionizing how organizations view excellence in their engineering disciplines.
“Most people think about competitive moats related to patents, networking effects, or brands,” Victor says. “In software, velocity is paramount. The winners aren’t necessarily those with bright ideas,” he continues, “but those who can execute those ideas most rapidly and successfully. This is the essence of platform engineering, which sees internal developer platforms (IDPs) not merely as infrastructure but rather essential software products,” Victor says. “In Victor’s five years’ experience, he has witnessed a paradigm shift regarding how engineering shops function.” From patching together ad-hoc tooling and bespoke scripts, there is a growing emphasis on integrated platforms that simplify complexity and trim the amount of time it takes to get software to market.
The economics make sense. The more time developers can free up from worrying about deployment pipes, strange infrastructure problems, or DevOps tickets, the more time they have to work on adding features to directly serve customers. As Victor points out, such organizations can experience anywhere from 30 to 50 percent increased productivity on the part of their developers.
This journey from traditional DevOps to platform engineering is more than an evolution in name only. Victor summarizes this transition as “a paradigm shift on how we, as engineering organizations, think about our work.” The DevOps days were epitomized by “you build it, you run it,” which moved runtime ownership into the hands of development teams. This helped to remove silos but introduced a new issue where every team essentially developed its own infrastructure on its own because each one solved similar problems in its own way, making onboarding difficult for new engineers.
Platform engineering reverses this paradigm by building a dedicated team to construct and manage a golden path that developers can follow. As a consequence, rather than each engineer needing to know how to work with Kubernetes, CI/CD tooling, observability, and security compliance, this work can be distilled into self-serve tooling that has outstanding documentation and intuitive UIs.
Developers gain maximum available power and flexibility, but they don’t have to deal with complexity. It’s like comparing building a website with raw HTML back in the ’90s vs. building one with a modern framework.” This method does not make expertise unnecessary but instead focuses this expertise on platform teams while still allowing product engineers to leverage what they do best. This helps to create a force multiplication effect where improvements on the platform impact every other function within the organization at the same time.
Victor explains that to think of an internal developer platform as a product is to understand your users, to have developers do user research, to analyze adoption metrics, and to iterate accordingly. This is a paradigm shift. The platform teams have to start thinking about app developers like customers, whose needs have to influence what is prioritized on their roadmap. They design surveys, usability studies, and measure other metrics such as deployment rate, recovery time, and satisfaction scores of app developers.
The competitive strength that comes with developed internal platforms is evident on a number of fronts. The biggest is that they allow organizations to significantly shorten cycle times. As Victor has worked with organizations on developed platforms, he has seen organizations go from being only able to deploy once a month to multiple deployments daily.
Besides scalability, platforms offer consistency and decrease variability. The consistency comes from having standardized processes for deploying applications, security features embedded into those applications, and automatically checked compliance rules, such that less-experienced engineers can also roll out applications without generating possible points of failure. The impact is rapid hiring and onboarding because new employees can quickly become productive.
Perhaps most importantly, having a strong internal platform makes it an asset of the company that is hard to duplicate by its rivals. While it is true that a rival company could poach its engineers, it is much more difficult to duplicate its knowledge and processes that are part of a strong platform.
Victor points out another less-often-considered aspect concerning talent acquisition and retention. More and more, engineers are making judgments about prospective employers based on their development experience. A company with outstanding tooling is more attractive to hire and keeps employees longer because they actually enjoy being part of a company that keeps infrastructure friction out of their work. Platform engineering can, to a degree, involve culture and processes rather than technology, but technology is, nevertheless, crucial. Victor has experience with different approaches to platform engineering and has noticed trends concerning what is best. Good platforms usually build on a few primary functions.
At this root layer, there is infrastructure as code and declarative configuration management. Rather than navigating web UIs or running imperative commands, developers can state what they want their infrastructure to look like, and the platform can compare what is to what should be. This declarative style, exemplified by Terraform and increasingly native to cloud providers, adds reproducibility and versioning to infrastructure management. Container orchestration, via Kubernetes or its more polished variants, gives applications running on those containers a consistent environment across development, staging, and live. Though Kubernetes is quite complex, platform teams layer simpler interfaces on top to allow applications to run on these platforms without developers having to grapple with pod definitions and service mesh complexities.
Continuous integration and deployments represent another very important cornerstone. Cloud platforms offer templated pipe lines which can build, test, scan for security, and deploy applications with ease. This is because one can simply point to where their repository exists, and everything is handled by this platform. They also offer rollbacks automatically on detection.
Observability is the last crucial piece. The platforms allow logs, metrics, and traces to be collected across all services and viewable through a cohesive interface, making it much faster to debug live problems. If there is an issue, developers can fix it without having to access servers via ssh or putting together information gathered by multiple monitoring services.
Victor stresses that it’s less about what specific tools one uses and more about having an integrated experience. “You can build a great platform using open source tooling, cloud native services, or bespoke solutions,” he says. “What matters is that everything is integrated seamlessly and provides a well-designed experience to the developers.”
Platform teams require metrics to provide direction on what they should work on and how they can prove value to their organization’s management. Victor recommends having both a system perspective and a perspective on how developers experience these systems. From a technical perspective, DORA metrics such as deploy frequency, lead time on change, time to restore service, and change failure rate measure technical excellence. The best organizations deploy frequently each day, restore services within an hour, and keep failure rates on change below 15 percent.
Metrics on developer satisfaction complement these technology metrics. These range from regular surveys about experience and Net Promoter Scores on internal tool usage to qualitative feedback on how engineers feel about their tooling. Platform adoption metrics measure how successfully developers are using what is called the golden path versus working around it, which shows how well the platform solves their problems. Resource utilization and cost metrics are important, and this is particularly true about inefficient infrastructure on cloud platforms because it directly affects bottom-line outcomes. A good platform empowers developers to optimize their resource usage.
Success on a platform is not necessarily ensured by technical excellence. Victor has noticed that organizational design is a huge factor in determining how effectively a platform is developed, because Conway’s Law holds true: The design of a system matches and mirrors the communication structure of the organizations building such systems. The design of such a team is crucial to having a productive one. Platform engineers require a distinct skill set that blends knowledge about infrastructure, product management acumen, and communication competence. They should feel at ease with uncertainty, deal effectively with trade-offs, and know how to influence others because they are more about facilitating rather than directly controlling applications.
Who they report to is very important. The platform teams require sponsorship and enough autonomy to make architectural choices without having to deal with red tape. They should operate close enough to product teams to understand their needs but far enough to make decisions that are more aligned with what is best for the business rather than what is best for a specific request.
Victor has observed how successful platforms function when they are structured like internal startups, complete with a charter, budget, and outcomes to execute on. This gives them the agility to make big bets while still being responsible for what they can accomplish. Platforms that are implemented on a part-time basis are less successful because this usually leads to subpar results and a hit-or-miss methodology.
From this experience, Victor has identified some common pitfalls in platform initiatives. The first is building out too much, too quickly. This is because platform initiatives tend to go after solving every possible pain point at once, which can take years to implement and is no longer what’s required when implementation is finally realized. The best way to approach this, according to Victor, is to start with what hurts developers the worst and work up to more after obtaining initial success.
Another common issue is having too little abstraction layering. A platform that only wraps other tools without hiding complexity will offer no value. The developers will still require strong infrastructure knowledge, thus negating the whole idea of having a platform. A platform with very strict abstraction that doesn’t support any kind of escape hatches to address unusual needs will lead to frustration on one hand and operating outside of the platform on the other.
Failure to invest in documentation and educating developers is a third failure mode. A well-designed platform will fail to thrive if developers are not equipped to take advantage of it. Successful platform organizations invest considerable resources into documentation, comprehensive onboarding programs, and educating developers on how to leverage new functionality.
The purpose of a platform is to serve its users, and satisfying them should ultimately be what success is defined by. This is no more than what one expects, but Victor goes on to say how he believes it can often sit at odds with technical excellence with platform teams. As software continues to take up more and more of the economy, and as more and more competition rewards iterative velocity, the strategic imperative to build and leverage internal developer platforms will likely continue to increase. This is because organizations that view platform engineering as a strategic function rather than a support function are better positioned to outperform their competition on velocity, quality, and experience. Victor’s insight, which is informed by five years of direct experience across multiple organizational environments, is that true platform engineering requires finding this middle ground between technical capability and product excellence.
The most exceptional platforms are those which do not seek to display technical acuity but rather simplify every interaction to one more opportunity to delight their customers and remove barriers out of their way. For those organizations that are serious about having a chance to compete within software-intensive industries, it is no longer a question of whether they should invest within platform engineering but how quickly they can develop this capability. The competitive barrier they build within this value proposition measured by the velocity of deployments, productivity, and compounded value over time could ultimately offer more long-term protection than any product capability and positioning.