Resume Examples
Platform Engineer Resume: Real Examples, System Design Thinking, and What Hiring Panels Actually Look For
A platform engineer resume usually fails for a simple reason: it reads like a list of infrastructure tools instead of a record of engineering leverage. Candidates mention Kubernetes, Terraform, AWS, CI/CD, Docker, observability, and internal tooling, but they do not make it clear what changed because of their work. Hiring teams already assume a platform engineer has touched those tools. What they want to understand is whether you built systems that made many engineers faster, reduced operational chaos, improved release confidence, and created durable standards across teams.
That is what makes this role harder to position than DevOps, SRE, or infrastructure engineering. Platform engineering is not defined by one toolchain. It is defined by abstraction, scale, and adoption. A recruiter may initially scan for keywords, but the technical panel quickly shifts to different questions: Did this person create reusable patterns? Did they reduce friction for product engineers? Did they design platform capabilities that other teams could rely on without opening tickets every day? Did they improve both velocity and safety at the same time?
This page is built to help you write a platform engineer resume that answers those questions clearly. It goes far beyond a basic sample. You will see how hiring managers evaluate the role, how to distinguish platform work from adjacent functions, how to write bullets that show system impact instead of implementation trivia, how to structure your experience by seniority, and how to make the document ATS-friendly without flattening it into keyword soup. You will also find multiple example summaries, full experience samples, deep bullet rewrites, decision frameworks, and role-specific guidance for global hiring markets.
What platform engineering actually means
Platform engineering is best understood as internal product engineering for software teams. Instead of shipping customer-facing features, platform engineers build the paved roads that product teams use to ship safely and quickly. That can include self-service deployment workflows, golden paths for new services, reusable infrastructure modules, secret management flows, observability standards, internal developer portals, test environments, policy guardrails, and runtime platforms. The common thread is not infrastructure ownership by itself. The common thread is developer enablement through engineered abstractions.
This matters on a resume because many candidates accidentally describe their work as a collection of ops tasks. That weakens the narrative. A stronger narrative shows how you reduced repeated toil, standardized patterns, and created systems that scaled beyond one team. The more your work looks like a platform product adopted by internal users, the more credible your resume becomes.
Core signals of platform work
- Reusable systems, not one-off fixes
- Internal adoption across multiple teams
- Developer workflow improvements
- Safer, faster release patterns
- Standardization without heavy friction
- Clear operational and productivity gains
How hiring panels evaluate a platform engineer resume
Platform engineer hiring usually happens in layers. The first pass is often done by recruiting or talent operations, which means the resume still needs recognizable terminology: cloud platforms, infrastructure as code, deployment pipelines, containers, orchestration, monitoring, developer tooling, and system design concepts. But getting through that screen is the easy part. The harder part is surviving technical review. Experienced interviewers are not impressed by long tool lists because most of those tools are table stakes for the role.
When a senior platform engineer, engineering manager, or staff-level infrastructure reviewer reads your resume, they are usually trying to infer five things. First, your scope: how many teams, services, or environments your work touched. Second, your design maturity: whether you built maintainable patterns or just automated local pain. Third, your product thinking: whether you considered adoption, usability, and internal customer needs. Fourth, your operational judgment: whether you improved safety and resilience rather than merely optimizing for speed. Fifth, your communication strength: whether you can explain complex system work in outcome-oriented language.
A good platform engineer resume therefore feels less like an admin log and more like a sequence of leverage points. Each major bullet or project should signal that you saw a repeated engineering problem, designed a platform-level solution, got teams to adopt it, and improved something measurable such as deployment lead time, onboarding friction, release reliability, cloud spend efficiency, infrastructure consistency, or observability coverage.
Platform engineer vs DevOps vs SRE vs infrastructure engineer
One of the biggest resume mistakes in this category is role blur. Many candidates have work that overlaps DevOps, SRE, cloud, and platform engineering, which is normal. But if the resume does not position that overlap carefully, hiring teams project the wrong identity onto the candidate. This is especially common when the person is doing platform-heavy work inside a company that still uses the title DevOps engineer.
DevOps
Usually emphasizes CI/CD, release automation, environment setup, and cross-functional operational support. Strong overlap with platform, but often narrower in internal product design.
SRE
Usually emphasizes reliability, SLIs and SLOs, incident response, observability, and failure reduction. More production health oriented than developer experience oriented.
Infrastructure
Usually emphasizes cloud resources, networking, provisioning, and runtime environments. Can be highly technical but not always framed as a platform consumed by internal users.
Platform
Emphasizes paved roads, self-service capabilities, standardization, reusable abstractions, and measurable developer productivity gains across many teams.
You do not need to erase overlap to position yourself well. You need to choose the lens. If you are targeting platform engineer roles, your bullets should tilt toward leverage, internal adoption, and workflow enablement even when the underlying technical work includes pipelines, Kubernetes, or infrastructure as code.
The system leverage formula for writing better bullets
A useful writing pattern for this role is:
Recurring engineering problem → platform or system solution → adoption scope → measurable effect
This works because it mirrors how strong platform work is recognized internally. The problem should be something structural, not incidental: inconsistent deployments, slow service onboarding, fragmented observability, environment drift, manual secret handling, poor rollback behavior, flaky ephemeral environments, or unclear runtime ownership. The solution should sound like an engineered system or repeatable pattern, not a loose collection of scripts. The scope should make clear that more than one person benefited. The effect should ideally be measurable.
Candidates often stop at the solution and forget the rest. That is why their bullets sound flat. A sentence like “Built Terraform modules for infrastructure” is not wrong, but it is incomplete. It omits why the work mattered and who benefited. A stronger version might say that you built reusable Terraform modules to standardize service provisioning across six product teams, reducing new environment setup time from two days to under one hour and eliminating configuration drift between staging and production. Same technical work. Completely different hiring signal.
Bullet rewrites: weak vs strong platform language
Weak: Managed Kubernetes clusters.
Stronger: Standardized Kubernetes deployment patterns across 40+ services, giving engineering teams a consistent runtime model and reducing failed releases caused by configuration mismatch.
Weak: Worked on CI/CD pipelines.
Stronger: Built reusable CI/CD templates and release guardrails adopted by eight engineering teams, cutting service onboarding time and reducing manual deployment steps in high-change environments.
Weak: Used Terraform to provision infrastructure.
Stronger: Created Terraform modules for networking, compute, and managed services that standardized provisioning across regions and reduced environment setup drift across dev, staging, and production.
Weak: Automated deployments.
Stronger: Automated multi-stage deployment workflows with approval controls, rollback hooks, and environment checks, improving release speed while lowering change failure rates.
Weak: Built internal tools.
Stronger: Developed internal self-service tooling for service creation and environment provisioning, removing repetitive ticket-based setup work and accelerating new service launch for product teams.
Weak: Improved developer experience.
Stronger: Reduced developer friction by packaging common deployment, secrets, and observability requirements into documented platform templates, cutting setup ambiguity for new services.
Weak: Supported cloud migration.
Stronger: Led platform-side migration patterns for legacy services moving to cloud-native infrastructure, giving teams standardized deployment and runtime paths instead of bespoke migration scripts.
Weak: Worked with monitoring tools.
Stronger: Defined baseline observability packages for services, improving log, metric, and alert consistency so teams could launch with stronger default visibility and faster production diagnosis.
Weak: Helped engineering teams deploy faster.
Stronger: Reworked deployment workflows and default service templates so product teams could move from repo creation to first production deployment with significantly fewer manual handoffs.
Weak: Improved infrastructure reliability.
Stronger: Introduced platform-level environment validation, deployment checks, and safer defaults that reduced release-related incidents and improved confidence in shared runtime infrastructure.
Resume summary examples for different levels
Weak summary
Platform Engineer experienced in AWS, Kubernetes, Terraform, Jenkins, Docker, and Linux. Passionate about infrastructure, automation, and improving developer productivity.
Stronger summary
Platform Engineer with 6+ years of experience designing self-service infrastructure, deployment standards, and runtime guardrails for cloud-native product teams. Recent work standardized service onboarding across eight teams, reduced release friction, and improved consistency across multi-environment deployments.
Early-career
Platform-minded infrastructure engineer with 2+ years of experience supporting internal deployment automation, cloud provisioning, and service reliability. Strong foundation in Kubernetes, Terraform, and scripting with growing ownership of reusable tooling for engineering teams.
Mid-level
Platform Engineer with 4+ years of experience building internal tools, CI/CD standards, and infrastructure modules that simplify developer workflows. Proven track record of improving service onboarding speed, reducing configuration drift, and scaling consistent engineering patterns across distributed teams.
Senior
Senior Platform Engineer specializing in internal platform architecture, developer experience, and large-scale cloud standardization. Experienced in building paved-road systems that balance autonomy and governance while reducing release complexity across high-growth engineering organizations.
A full example: mid-level platform engineer experience section
Platform Engineer
Northbridge Software • Remote • Mar 2022 – Present
- Built reusable service templates and delivery pipelines for product teams, reducing repeated platform setup work and making it easier to launch new services with compliant defaults.
- Created Terraform modules for networking, compute, and managed data services, improving provisioning consistency across environments and reducing environment-specific drift.
- Standardized container build and deployment flows for a growing microservices estate, giving engineering teams a shared path for testing, release, and rollback behavior.
- Worked with developers to package observability defaults into platform standards, improving out-of-the-box metrics, logs, and alert readiness for newly deployed services.
- Reduced ticket dependency on the platform team by building self-service workflows for common infrastructure requests, allowing product teams to move faster without bypassing governance.
- Partnered with security and operations stakeholders to embed policy checks into deployment workflows, balancing delivery speed with release quality and platform safety.
A deeper example: senior platform engineer section with stronger leverage signals
Senior Platform Engineer
Atlas Cloud Systems • Berlin • Jan 2020 – Present
- Designed an internal platform strategy for service delivery and runtime standards across 12 engineering teams, replacing fragmented deployment approaches with a shared paved-road model.
- Led the creation of self-service provisioning workflows that reduced engineering wait time for common environment requests and increased adoption of approved infrastructure patterns.
- Introduced reusable guardrails for rollout checks, secrets handling, service configuration, and runtime observability, improving release consistency across high-frequency deployment environments.
- Worked with staff engineers and engineering managers to define what teams could customize versus what the platform should standardize, reducing friction between autonomy and governance.
- Established internal platform documentation, templates, and onboarding flows that made platform capabilities easier to discover and reduced reliance on tribal knowledge.
- Mentored platform and infrastructure engineers on framing work around internal customer needs, helping the team move from reactive support patterns to productized platform thinking.
How to write about internal tools without making them sound small
Many platform engineers undersell their best work because the outputs are internal. They think the absence of customer-facing visibility makes the work sound less impressive. That is usually the opposite of what technical hiring panels think. Internal platforms can be some of the highest-leverage systems in an organization because they affect how dozens or hundreds of engineers build, test, deploy, observe, and operate software.
The key is to write internal tools as internal products. That means naming the user problem, the adoption pattern, and the measurable value. For example, instead of “built a portal for developers,” explain that you built an internal service creation portal that packaged deployment scaffolding, secret wiring, observability defaults, and policy checks into a single guided flow, reducing new-service setup time and improving compliance with platform standards. That reads like a product. It has users, an experience, and an outcome.
This framing is especially important for candidates moving from infra-heavy companies into mature platform engineering organizations, where internal developer experience is taken seriously and platform adoption behaves more like product adoption than like central operations support.
A practical case study: turning ticket-heavy infrastructure support into a platform capability
Imagine a company where product teams depend on the infrastructure group for every environment change, queue creation, access adjustment, or service deployment tweak. The central team is overwhelmed. Product engineers wait for support. Workarounds begin to appear. Standards become inconsistent because the process is too slow and too opaque.
Platform engineering solves this differently from traditional ops support. Instead of closing tickets faster, the platform engineer asks which requests are repeated often enough to become productized. Then they define safe self-service pathways. They may create requestless provisioning for approved resources, service templates for new workloads, automated policy checks, environment recipes, and documented golden paths. The result is not simply lower ticket volume. The result is a new interaction model where developers can move independently inside strong guardrails.
On a resume, that transformation can be described in several ways depending on your exact contribution. You might emphasize self-service provisioning, standard templates, reduced support dependency, improved policy adherence, or faster delivery. What matters is showing that you changed the system rather than heroically absorbing more operational work.
This distinction is powerful in interviews too. Strong platform candidates tend to think in terms of productizing common paths, shaping adoption, and reducing cognitive load for internal users. Resumes that capture that mindset stand out quickly.
What to emphasize at each seniority level
Early-career
Show that you understand the building blocks: IaC, pipelines, containers, cloud services, scripting, Linux fundamentals, and deployment workflows.
Even if you do not yet own platform architecture, you can still signal platform potential by describing how you contributed to reusable systems, reduced repetitive work, or improved consistency for others.
Mid-level
This is where the resume should show end-to-end ownership of platform components or workflows. Hiring teams want to see that you can identify recurring engineering pain, design a solution, and drive adoption.
Metrics become especially useful here: onboarding time, deployment time, release quality, environment consistency, or support reduction.
Senior or staff
Senior resumes must show platform strategy, not just strong implementation. That includes tradeoffs, adoption design, platform boundaries, governance models, and influence across teams.
This level should also show how you aligned platform decisions with engineering productivity, security, reliability, and organizational scale.
The most important metrics for platform engineer resumes
Not every role has obvious platform metrics, but when you can quantify outcomes, it strengthens your resume substantially. The best metrics in this category are usually operationally meaningful rather than flashy.
Good metric categories
- New service onboarding time
- Deployment duration or manual steps removed
- Adoption across teams or services
- Reduction in configuration drift or release failures
- Lower ticket volume for common infra tasks
- Improved observability coverage or baseline compliance
- Environment provisioning speed
- Reduced cloud waste through standardization
Metrics to avoid overstating
- Huge uptime claims when reliability was shared broadly
- Productivity gains with no basis or comparison window
- Cloud savings not clearly attributable to your work
- “Improved performance” without naming what improved
- Vanity metrics unrelated to internal platform value
Precision helps. If you do not have perfect numbers, you can still write credibly by using bounded or directional language such as “reduced repeated setup work,” “cut onboarding friction,” or “standardized runtime defaults across several teams.” The goal is credibility first, precision second.
Fifteen more rewrite patterns to strengthen weak bullets
Before: Maintained cloud accounts.
After: Standardized cloud account setup and baseline controls to reduce environment inconsistency and simplify cross-team provisioning practices.
Before: Built scripts for developers.
After: Replaced ad hoc developer scripts with maintained platform utilities that packaged common infrastructure and deployment operations into safer, repeatable workflows.
Before: Helped set up new microservices.
After: Created service bootstrap templates that bundled build, deploy, logging, metrics, and policy defaults, reducing the effort required to launch new microservices.
Before: Added security checks to pipelines.
After: Embedded platform-level validation and policy checks into delivery workflows so teams could move faster without bypassing release controls.
Before: Supported developer requests.
After: Converted repeated developer support requests into self-service platform capabilities, lowering dependency on direct platform intervention for routine changes.
Before: Worked on observability.
After: Standardized service instrumentation and baseline telemetry expectations so engineering teams launched with stronger default visibility and fewer monitoring gaps.
Before: Managed developer environments.
After: Simplified local and shared development environment setup through documented templates and platform automation, reducing onboarding friction for new engineers.
Before: Improved release process.
After: Redesigned release workflows with safer defaults, validation steps, and rollback readiness, helping teams ship more confidently in high-frequency deployment environments.
Before: Built automation around secrets.
After: Reduced secrets-handling errors by integrating secret management patterns directly into platform templates rather than relying on manual configuration knowledge.
Before: Supported platform migrations.
After: Designed migration paths and compatibility patterns that helped teams move to approved platform standards without reworking every service from scratch.
Before: Optimized cloud resources.
After: Improved cloud efficiency by turning cost-aware defaults into shared platform patterns instead of relying on service-by-service manual tuning.
Before: Created documentation.
After: Wrote adoption-focused platform documentation that reduced ambiguity for internal users and improved discoverability of approved engineering paths.
Before: Collaborated with developers.
After: Gathered developer feedback on onboarding pain points and used it to redesign platform workflows around actual user friction rather than platform team assumptions.
Before: Built internal APIs.
After: Exposed platform capabilities through internal APIs and templates that made common service lifecycle tasks easier to automate and standardize.
Before: Reduced incidents.
After: Lowered release-related operational risk by packaging safe deployment behaviors, validation checks, and baseline observability into shared platform workflows.
How to position architecture and system design without sounding inflated
Platform engineers often do architecture work, but candidates sometimes overstate it by using grand language with little evidence. The safest way to present architecture is to describe actual design decisions, constraints, and adoption patterns. For example, you might explain that you designed a platform approach that separated customizable service settings from non-negotiable runtime controls, allowing teams to move quickly while preserving compliance and operability. That sounds real because it captures a design tradeoff.
Another strong pattern is to show the boundary you created. Platform architecture is often about defining which concerns the platform owns centrally and which concerns remain in application teams. Good resumes signal that the candidate understands these boundaries. They do not claim to “architect the cloud.” They show that they designed a reusable approach to service provisioning, service delivery, identity flows, runtime defaults, or observability integration.
At senior levels, this is where your resume starts to differentiate itself. Strong platform engineers do not just automate. They shape how engineering work gets done at scale.
Platform engineer skills section: what belongs and what does not
The skills section matters because ATS systems still rely on keyword matching, but it should not become an uncontrolled dumping ground. A useful platform engineer skills section groups tools by capability so the reader can understand both breadth and depth quickly.
Better grouping
Cloud & runtime: AWS, GCP, Azure, Kubernetes, Linux
Infrastructure as code: Terraform, Pulumi, CloudFormation
Delivery & automation: GitHub Actions, Jenkins, Argo CD, scripting
Observability: Prometheus, Grafana, Datadog, OpenTelemetry
Platform concepts: self-service tooling, golden paths, policy guardrails, developer experience
What weakens the section
Extremely long lists of tools with no grouping, vendor names you barely used, every cloud service you touched once, repeated items already obvious from experience bullets, and generic soft skills with no evidence elsewhere in the resume.
The best skills sections support the story your experience section already tells. They should not try to tell a different story.
Common mistakes that make a platform resume look shallow
Patterns that hurt
- Making the resume a cloud tool inventory
- Describing support tasks instead of platform outcomes
- Using “improved developer experience” with no evidence
- Ignoring internal adoption and user impact
- Overclaiming architecture without naming tradeoffs or scope
- Mixing SRE, DevOps, and platform language randomly
- Leaving out documentation, discoverability, or onboarding gains
Patterns that strengthen
- Writing in terms of systems and repeated engineering pain
- Showing adoption across teams and services
- Including specific workflow or reliability improvements
- Explaining platform work as internal product work
- Using metrics where possible, credible scope where not
- Showing balance between speed, governance, and usability
- Demonstrating platform thinking, not just automation skill
ATS optimization for platform roles without sounding robotic
ATS optimization still matters. For platform roles, common terms often include Kubernetes, Terraform, CI/CD, cloud infrastructure, infrastructure as code, internal tools, observability, developer experience, platform engineering, automation, and system design. But stuffing all of these into a block of text usually weakens the page. Strong ATS optimization comes from alignment, not repetition.
A practical method is to read the job description and categorize its priorities. Is the role platform-product focused? Is it runtime-focused? Is it delivery-pipeline focused? Is it heavily Kubernetes-oriented? Is it centered on developer portals and self-service? Once you know the center of gravity, mirror that language where truthful across your summary, skills, and experience bullets. That produces a resume that works for both scanning systems and human reviewers.
This is especially important in global hiring. Different companies may use different titles for very similar work. Some still advertise “DevOps Platform Engineer.” Others use “Developer Infrastructure Engineer” or “Cloud Platform Engineer.” Your resume should be flexible enough to align with those naming differences without diluting its core story.
How to handle projects, open source, and internal platform docs
Platform engineers often have less visually obvious portfolio work than frontend or product candidates. That does not mean they have no portfolio value. Open-source contributions, reusable tooling, example platform modules, architecture notes, internal RFC leadership, or documented migration patterns can all help if they are presented selectively and professionally.
If you include projects, prioritize ones that show repeatability and system thinking: a self-service environment tool, deployment templates, local development orchestration, observability starter kits, platform APIs, service scaffolding, or policy automation. Do not add hobby projects that have little connection to your target role just to fill space.
Documentation can also be a signal of maturity. A candidate who can build a strong platform and make it discoverable is often more valuable than one who built clever automation that nobody else can use confidently.
Three complete experience examples you can model from
Example 1: Early-career platform engineer
Cloud Operations Platform Associate • May 2023 – Present
- Supported the rollout of shared deployment templates for backend services, helping engineering teams move from manually curated release steps to a more consistent delivery workflow.
- Contributed to Terraform module maintenance for common infrastructure resources, improving provisioning repeatability and reducing copy-paste environment setup patterns.
- Worked with senior platform engineers to document service onboarding steps and internal setup expectations, making it easier for new engineers to understand approved platform paths.
- Automated routine environment validation checks with scripting, lowering repetitive manual verification work before deployments and reducing avoidable release mistakes.
Example 2: Mid-level platform engineer
Platform Engineer • Jan 2021 – Present
- Designed reusable service bootstrap templates that packaged delivery, runtime, observability, and configuration defaults into a documented paved road for product teams.
- Reduced service launch complexity by standardizing environment provisioning and deployment steps, helping developers reach production with fewer tickets and less platform-team intervention.
- Built and maintained common Terraform modules for compute, networking, and managed dependencies, increasing consistency across environments and reducing local team variation.
- Introduced workflow guardrails into CI/CD systems so teams could move faster while retaining stronger default checks around deployment quality and policy adherence.
- Partnered with internal users to improve platform usability, treating platform adoption as an internal product problem rather than a pure tooling problem.
Example 3: Senior platform engineer
Senior Platform Engineer • Jul 2019 – Present
- Defined platform strategy around self-service infrastructure, runtime standards, and deployment governance for a growing engineering organization with multiple autonomous product teams.
- Balanced team autonomy with platform consistency by separating configurable application concerns from centrally managed operational requirements and platform guarantees.
- Led the rollout of a shared internal platform model that reduced duplicated team-by-team engineering effort and improved clarity around approved build and deploy patterns.
- Worked cross-functionally with security, operations, and staff engineering stakeholders to align platform capabilities with reliability, compliance, and developer productivity goals.
- Mentored engineers on writing platform work as leverage-driven engineering rather than support work, improving how the team communicated impact to leadership and hiring panels.
Interview-driven resume advice: write to the questions you will later be asked
A strong platform engineer resume should not only help you pass screening. It should also set up good interviews. The best bullets naturally lead to useful follow-up questions: how you defined the platform boundary, how you handled adoption resistance, how you chose what to standardize, how you designed rollback or validation behavior, how you measured platform success, and how you balanced speed with governance. If a bullet cannot produce an interesting technical conversation, it may still be too shallow.
For that reason, avoid vague claims such as “improved developer experience” or “optimized infrastructure.” Those are outcomes only if you can explain what changed mechanically. Did you remove approval steps? Did you unify service templates? Did you package observability defaults? Did you convert repeated chat support into discoverable workflows? Did you reduce environment variance? Did you improve deploy confidence through guardrails? Concrete mechanics make your resume more believable and make later interviews stronger.
Think of your resume as a map of technical conversations you are ready to have. If it is written that way, both recruiting and hiring panels will trust it more.
A checklist for your final edit before applying
- Does your summary position you as a platform engineer rather than a generic infrastructure engineer?
- Do at least half your bullets show internal users, adoption, or leverage across teams?
- Have you reduced tool repetition and increased outcome clarity?
- Do your strongest bullets include scope, systems, or measurable effects?
- Have you shown how your work improved delivery, reliability, or developer workflow?
- Does the resume show reusable patterns instead of isolated tasks?
- Would a hiring manager understand what changed because of your work?
- Could you defend every major claim with a technical story in interview?
- Are platform, DevOps, and SRE terms used intentionally rather than interchangeably?
- Does the page sound like internal product engineering rather than reactive support?
What a great platform engineer resume leaves the reader thinking
The best possible reaction from a hiring panel is not “this person knows Kubernetes.” It is something more like: this engineer understands how to turn repeated engineering pain into maintainable platform capabilities; they think about internal users; they care about adoption; they can improve delivery quality without becoming a bottleneck; and they can scale patterns across teams without losing clarity.
That reaction comes from the accumulation of small writing choices. It comes from replacing tool-centric bullets with leverage-centric bullets. It comes from showing internal product thinking. It comes from including scope, adoption, and workflow outcomes. It comes from sounding like someone who designs systems around users and operational realities, not someone who merely touched a stack of infrastructure technologies.
If your current resume still reads like generalized DevOps work, the fix is usually not to add more tools. The fix is to sharpen the story around platform value. Show what you standardized, what you productized, what you removed from the critical path, what you made safer by default, and what became easier for engineers because you were there. That is the signal that gets remembered.