Platform work is a different kind of engineering

Building platform engineering solutions is a lot like assembling a Gundam model kit. The product engineers are the ones who snap the pieces together and build the finished robot. The platform team builds the clippers, files, and display case—the tools that make the assembly possible. They do not build the Gundam itself, but they ensure the person who does has everything they need.

After GitHub’s infrastructure organization absorbed a product-focused team, that distinction became real. Previously, the team solved external problems, like building the deployment views across environments. Now, with internal customers, the way they test code and approach problems has changed. The work shifted from delivering features to building the components that others build on.

Start with the domain

Before touching a problem, you must understand the domain: the business and technical area where your team operates. Learn the technical terms and how the systems overlap to deliver fast, reliable solutions. Getting up to speed involves:

  • Talk to your neighbors: Schedule a handover meeting with a team that knows the subject well. Use the time to clarify terminology and the problems you’ll be tackling.
  • Investigate old issues: Stale or persistent tickets in the backlog reveal the system’s current limitations and the spots most ready for improvement.
  • Read the docs: Documentation is a rich source of knowledge for understanding how the system operates.

Platform teams, acting as the foundational layer, need a deeper grasp of several technical areas:

  • Networks: Familiarity with TCP, UDP, and L4 load balancing, plus debugging tools like dig, is essential. You need to understand how network traffic impacts your platform even if you are not a network operator.
  • Operating systems and hardware: Choosing the right virtual machines (VMs) or physical hardware affects scalability and cost. Operating system selection is equally important for avoiding vulnerabilities or end-of-life systems.
  • Infrastructure as Code (IaC): Tools like Terraform, Ansible, and Consul cut down on human error during machine provisioning and modifications. They are becoming a core requirement.
  • Distributed systems: Platform problems come with the expectation that failures happen. Proactive failover and recovery mechanisms are essential to maintain reliability. The right approach depends entirely on the problem and desired system behavior.

Why sharing knowledge matters

Sharing what works—and what does not—brings new perspectives and avoids repeated mistakes. Knowledge sharing matters for three reasons:

  • Teamwork accelerates progress: Engineers resolve issues faster and innovate when they can learn from, and build on, each other’s ideas.
  • It prevents lost knowledge: When lessons stay with one engineer, the information disappears when they leave or are unavailable.
  • It improves customer success: Shared lessons help the team build reliable, scalable, and secure platforms that serve customer needs.

Watch the impact radius

The biggest practical difference between product and infrastructure engineering is impact radius. Platforms are the building blocks of the system, so even a small change can ripple across many products. At GitHub, the team that owns DNS is responsible for a service that countless other features depend on. A minor change there can affect everything from GitHub Pages to GitHub Copilot. To manage that risk:

  • Map your dependencies: Talk directly to teamsthat rely on your service to understand how proposed changes affect them.
  • Review postmortems: Study past incidents with the question, “What was the impact?” to understand what failure was introduced, how the platform factored into it, and how it was resolved.
  • Use condensed telemetry: Consolidate monitoring and logging into a small, quickly digestible dashboard, such as a Single Availability Metric (SAM). The ability to glance at one view helps engineers locate the source of an issue faster than interpreting many detailed logs.

Testing in a distributed environment

Testing distributed environments is hard, especially for a foundational service like DNS. The key is using a test site as a real machine to validate changes. In practice:

  • Test IaC fundamentals: With Terraform or Ansible, practice provisioning and deprovisioning machines. When a machine needs to be re-provisioned, ensure it is not accidentally deleted and that you can spin up a new one.
  • Run End-to-End (E2E) checks: Direct some traffic to the test servers. Observe host behavior directly or divert a small portion of traffic to evaluate functionality.
  • Test self-healing: Simulate unexpected loads to confirm the platform can recover and to spot bottlenecks before they reach users. Early identification is crucial for maintaining platform health.

Once tests pass, implement changes host by host. That way you can roll back an individual machine without affecting every host in the environment.

Platform engineering is hard because the systems are complex and full of moving parts. But watching it come together makes it worth it. When the platform runs smoothly, engineers ship faster and more reliably—and the work behind the scenes pays off in a platform that teams can confidently build on.